Data management plans
A Data Management Plan (DMP) is the policy record that governs how a Project's Lab Results are interpreted, converted, summed, and reported. It carries the rules an analysis run applies to raw lab values: what unit each method reports in, how summed analytes such as Total PCBs are computed, how non-detects are substituted, and how field-duplicate replicates are reduced to one value. Assigning a DMP to a Project is what turns its lab data into consistent, compliance-ready output.
When an analysis run combines several results into one value, the qualifier that carries forward is decided by propagation ranks set globally on each Qualifier in reference data — not on the DMP. A DMP applies those ranks during summation and duplicate aggregation; it does not configure them.
What a DMP controls
A DMP is a named, code-keyed aggregate: its Code is unique, while its Name is descriptive and may repeat. Only a Data Steward (the Administrator and Data Manager roles) can create or change one.
Each DMP carries two rule collections plus plan-wide non-detect and duplicate-aggregation settings:
| Component | What it does |
|---|---|
| Reporting-unit preferences | Set the target reporting unit per analysis Method, driving unit conversion |
| Summation rules | Define summed, aggregated, or computed analytes (for example ΣPCB, Total VOCs, TPH) from component analytes |
| Non-detect handling | Choose whether the detection limit or reporting limit substitutes for a non-detect, and how — including how a reported EMPC is treated for detected and non-detect results |
| Duplicate aggregation | Cluster field-duplicate replicates and reduce them to a single aggregate value |
The structural relationship is shallow: a DMP owns its two rule collections, and a Project points at one optional DMP. Qualifier propagation ranks are not part of the DMP — they live on the Qualifiers reference data and apply application-wide.
Figure: a Project is assigned at most one DMP, which owns its unit and summation rules.
Qualifier propagation
When the analysis pipeline combines several component results into one value, exactly one qualifier carries forward onto the result. Each component contributes its validated qualifier only — an unvalidated component brings none — so a summed or aggregated row's qualifier is always derived from its components' validated qualifiers. The winner is decided by the propagation ranks set on each Qualifier — the lowest rank number wins. Each code can set a detected rank (used when at least one matched result is detected), an all-non-detect rank (used when every matched result is a non-detect), or both.
These ranks are global: you set them once on each Qualifier in reference data, and every Project's analysis uses them. A DMP does not carry qualifier priorities — to change which qualifier wins, edit the codes in Qualifiers.
Reporting-unit preferences
A reporting-unit preference names the target unit a given analysis Method should report in. During analysis the analysis pipeline converts each matching result to that unit, so a dataset spanning several labs reads in one consistent unit. You can set different preferences for the same Method across different unit families — for example mg/L for water and mg/kg for soil — but not two preferences whose units share a compatibility group.
Summation rules
A summation rule produces a derived analyte from a set of component analytes. The rule names a target Analyte, a SummationType, the components that feed it, and how non-detects in those components are treated. The target analyte identifies the rule — a plan holds at most one summation rule per target analyte.
SummationType values:
| Value | Meaning |
|---|---|
Sum | Add the component values (the default) |
Average | Mean of the component values |
Max | Largest component value |
Min | Smallest component value |
Each rule also carries optional controls:
MinimumDetectedPercentage— require at least this share of components to be detected; if not met,ThresholdNotMetHandlingdecides the outcome (the two are set together or not at all).ApplicableFraction— restrict the rule to one fraction (for exampleTotalorDissolved).- Per component, an optional analysis Method and a positive
MultiplicationFactor.
A component cannot reuse the rule's target analyte. If some components pin a Method and others do not, the rule is skipped during analysis and you are warned. The analysis pipeline sums raw lab results only — it does not feed one rule's computed output into another.
Sums never mix analysis methods or reporting bases. When no component pins a Method, results group by method automatically and each method produces its own sum. Independently, results split by reporting basis — each of dry, lipid, and non-dry produces its own sum, so a dry-weight value is never added into a wet-weight total. As Received and Wet Weight are the same uncorrected measurement worded two ways and sum together; no rule configuration is needed for any of this.
To remove several components from a rule at once, tick the checkbox on each row (or the header checkbox to select the whole page) and select Delete selected (N) above the grid. Bulk deletion is permanent, requires the Data Steward role, and records each removed component individually in the Audit Log.
Non-detect handling
Non-detect handling has two layers. At the plan level, NonDetectLimitType selects whether the method detection limit (Detection Limit, the default) or the method reporting limit (Reporting Limit) stands in for a non-detect during substitution and screening. The value used follows a fixed precedence: a non-detect's recorded result value is used when it has one; otherwise the limit chosen by NonDetectLimitType is used, falling back to the other limit when the chosen one is missing, and finally to a reported EMPC when no limit is recorded at all. See EMPC handling for how a non-detect's EMPC can be made to supersede its limit outright. The plan's NonDetectDisplayFormat is a display hint only — it shapes how a non-detect renders (for example < RL or ND) and is not read by the analysis pipeline. The two With-Qualifier formats (Value With Qualifier, Less Than With Qualifier) append the result's validated qualifier; an unvalidated result carries none, so those formats fall back to the plain value or < limit — the < limit/ND notation still conveys non-detect status on its own, independent of any qualifier.
At the summation-rule level, DefaultNonDetectHandling controls how each non-detect component substitutes (As Zero (the default), As Half Limit, or As Full Limit), and DefaultAllNonDetectHandling controls the result when every component is a non-detect (Sum All Limits, Use Max Limit, As Zero (the default), or Use Max Limit Times Half). "Limit" in every case means the limit the plan's NonDetectLimitType selects — detection or reporting — so a plan screening against reporting limits substitutes half the reporting limit, not half the detection limit.
EMPC handling
An EMPC (Estimated Maximum Possible Concentration) is a lab-reported estimate for a detected-but-tentative signal — common in EPA dioxin/furan GC-HRMS methods (1613B, 8290A). Two plan-level settings decide how a reported EMPC folds into a result's effective value; both default to today's behavior, so a plan that changes neither reads exactly as before.
EmpcQuantifiedHandling— used when a detected result carries both a reported value and an EMPC. Use Reported Value (RV, the default) keeps the firm quantitation; Use Maximum (Max) takes the larger of the value and the EMPC (a conservative "never below the estimated maximum" choice).EmpcNonDetectHandling— used when a non-detect carries an EMPC. Ignore EMPC (Ign, the default) leaves the non-detect on its MDL/MRL ladder; As Limit (Lim) lets the EMPC elevate the plan's chosen limit, but only when the EMPC is higher (it never lowers a limit — an EMPC between the detection and reporting limits with the reporting limit selected still screens at the reporting limit), and when it does elevate, the row stays a non-detect shown as< EMPC; As Detection (Det) promotes the row to a detection with the EMPC as its concentration, which can raise a screening exceedance.
An EMPC is treated exactly as the plan configures it — as a detection or as a non-detect — so it needs no separate exceedance category; you can see that a value came from an EMPC by drilling into the result.
Validator judgment always supersedes the EMPC policy. A validated result value or detected flag overrides any EMPC substitution, and As Detection in particular never flips a non-detect that a reviewer has affirmatively confirmed as a non-detect (set Validated Detected to No): that row stays a non-detect, with the non-configurable no-limit floor still giving it a limit magnitude. And when As Detection promotes a result that still carries a validated qualifier — a reviewer set a qualifier but not the detected flag — analysis raises a review warning so someone can resolve the now-detected result that still carries a qualifier; the system does not silently reconcile it.
Two EMPC behaviors are baseline and are not DMP-gated — they apply to every project, including one with no DMP or where DMP rules are skipped: a detected result with a reported EMPC but no value or text uses the EMPC as its effective value, and a non-detect with no MDL or MRL at all but a reported EMPC uses the EMPC as its limit magnitude. Only the two configurable settings above require a DMP.
Duplicate aggregation
When a Project collects field-duplicate replicates, the DMP can reduce each cluster of replicates to a single aggregate value. Only the Normal and Field Duplicate sample types participate; the synthetic result is stamped with the sample type Aggregate so grids distinguish it from collected samples.
Four plan-level fields drive it:
DuplicateAggregationMethod—Average(default),Median,Maximum,Minimum,PrimaryOnly(drop duplicates with no math), orSeparate(no aggregation).DuplicateAggregationOrder— whether aggregation runs Aggregate Before Summation (the default) or Aggregate After Summation.DuplicateNdHandlingandAllDuplicateNdHandling— how non-detects in a cluster, and all-non-detect clusters, are reduced.
The aggregate's sample identifier is built from AggregatedSampleIdTemplate (default {PrimaryId}-{Aggregation}), which also accepts the {Method} and {ReplicateCount} tokens.
Each cluster aggregates one result per sample. When a sample carries more than one effective-reportable result for the same measurement — a re-run, or the same sample re-reported on a second lab report — a single result is selected: a validated result first, then the one with the newest analysis date. The passed-over rows still appear in the aggregate's detail panel, marked not selected, and the analysis warns so the ambiguity can be resolved at the source (set the superseded rows to Reportable Result No). The same selection rule decides which result a crosstab cell displays and which result a summation rule consumes, so an aggregate always reconciles with the values shown beside it. If the extra rows all belong to one sample — no field duplicate was actually collected — nothing is aggregated and the rows pass through unchanged.
Worked examples
The settings above combine per result. These examples trace a few common cases from the raw lab values to the reported number, holding every other setting at its default. The numbers are illustrative, not recommendations.
Summation with non-detects
A Total PCBs rule (SummationType Sum) adds three Aroclor components. The plan substitutes the detection limit for non-detects (NonDetectLimitType = Detection Limit), and one component is detected:
| Component | Result | Value or MDL |
|---|---|---|
| Aroclor 1016 | Detected | 2.0 µg/kg |
| Aroclor 1254 | Non-detect | MDL 0.50 |
| Aroclor 1260 | Non-detect | MDL 0.40 |
Because at least one component is detected, the total is a detected result, and DefaultNonDetectHandling decides how the two non-detects count toward it:
DefaultNonDetectHandling | Total PCBs |
|---|---|
| As Zero (default) | 2.0 + 0 + 0 = 2.0 |
| As Half Limit | 2.0 + 0.25 + 0.20 = 2.45 |
| As Full Limit | 2.0 + 0.50 + 0.40 = 2.90 |
If instead every component were a non-detect (say MDLs 0.60, 0.50, and 0.40), the total is reported as a non-detect, and DefaultAllNonDetectHandling sets the magnitude it carries:
DefaultAllNonDetectHandling | Total PCBs (reported as a non-detect) |
|---|---|
| As Zero (default) | 0 |
| Sum All Limits | 0.60 + 0.50 + 0.40 = 1.50 |
| Use Max Limit | 0.60 |
| Use Max Limit Times Half | 0.30 |
A per-component MultiplicationFactor — for example a toxicity-equivalence factor — multiplies that one component's contribution before it is summed. Sums never cross an analysis method or a reporting basis, so a dry-weight congener never lands in a wet-weight total (see Summation rules).
Duplicate aggregation
A primary sample and its field duplicate each report Benzene:
| Sample | Benzene |
|---|---|
| MW-01 (Normal) | 10 µg/L |
| MW-01-FD (Field Duplicate) | 14 µg/L |
DuplicateAggregationMethod reduces the pair to one reportable value:
| Method | Aggregate |
|---|---|
| Average (default) | 12 |
| Maximum | 14 |
| Minimum | 10 |
| Primary Only | 10 (keeps the primary, no math) |
| Separate | both rows pass through — no aggregate is formed |
The passed-over rows stay visible in the aggregate's detail panel, so you can always see what fed the reported value.
EMPC
A dioxin congener is detected, and the lab reports both a firm value and an EMPC:
| Reported | Value |
|---|---|
| Result value | 3.0 pg/g |
| EMPC | 5.0 pg/g |
EmpcQuantifiedHandling | Effective value |
|---|---|
| Use Reported Value (default) | 3.0 |
| Use Maximum | 5.0 (the EMPC is higher) |
If the same congener were instead a non-detect carrying an EMPC of 5.0 pg/g with a reporting limit of 2.0:
EmpcNonDetectHandling | Effective result |
|---|---|
| Ignore EMPC (default) | non-detect at the reporting limit, 2.0 |
| As Limit | non-detect at 5.0, shown < EMPC — the EMPC is higher than the limit, so it elevates it |
| As Detection | a detection at 5.0, which can raise a screening exceedance |
A validated result value or detected flag always wins over any of these EMPC substitutions.
To check how these rules resolved for a specific result, open the row's breakdown in the Data Explorer Result Detail panel or a Crosstab cell — it lists every component or source row and what each contributed to the reported value.
How a DMP shapes the analysis tools
A DMP changes nothing until results are analyzed. The analysis tools — Crosstab, Map, and Time Series — resolve the effective DMP from the projects in the result set and apply its rules in a fixed order, shown below: unit conversion, duplicate aggregation, then summation. Data Explorer applies the same rule set on its own result shape.
Figure: the order each result passes through. EMPC handling runs on every result — its floors apply even with no DMP. The three middle steps — unit conversion, duplicate aggregation, and summation — are the Data Management Plan's, and run only when the selected projects share one DMP. Screening runs last, against the Criteria Set you pick in the tool.
Duplicate aggregation runs before summation by default; a plan's DuplicateAggregationOrder can move it to after summation. Time Series takes the same prepared results but draws the Criteria Set as limit lines rather than a per-result screening verdict.
Resolution is all-or-nothing across the selection:
| Projects in the result set | Effect |
|---|---|
| All share one DMP | That DMP's rules apply to every result |
| Reference different DMPs, or some have one and others none | DMP rules are skipped and you are warned |
| None reference a DMP | DMP rules are silently skipped |
Because rules apply only when every selected project shares a single DMP, filter an analysis to projects with the same DMP to keep unit conversion, summation, and non-detect handling consistent. The two EMPC baseline behaviors are the exception — they apply even when a project has no DMP; only the two configurable EMPC settings are DMP-gated (see EMPC handling).
A Project may have no DMP — assignment is optional through its DataManagementPlanId.
Activate, supersede, and set a default DMP
Beyond its rules, a DMP carries a lifecycle status and two independent flags that govern how it is offered to projects.
| State | What it controls |
|---|---|
| Status | A lifecycle label — Draft, Under Review, Approved, or Superseded |
| Active / inactive | Whether the DMP appears in pickers. Deactivate one to retire it without deleting it |
| Default | Marks this DMP as the organization's standard plan for new projects. At most one DMP is the default |
You manage these from the plan's detail page: Activate or Deactivate it, and Set as Default or Clear Default. When you retire a DMP, you can also record the plan that supersedes it — its successor — capturing the lineage. A DMP named as another plan's successor (or still referenced by a Project) cannot be deleted. A DMP optionally belongs to an owning organization.
When you assign a DMP to a Project, the default plan is the one your organization treats as standard; you can accept it, pick any active DMP, or leave the Project with none. A Project with no DMP has DMP rules skipped during analysis.
Related
- Create data management plans and screening criteria
- Qualifiers — the global qualifier codes and the propagation ranks the analysis pipeline applies.
- Data Explorer
- Crosstabs
- Data Analysis & Screening
- Lab analyses and results