Environmental data terms, defined against the pipeline that implements them.

CHEMDAS resolves incoming analyte identifiers — CAS numbers, names, lab-local codes — to canonical analytes at import time. A CAS-keyed synonym dictionary (PubChem-derived registry synonyms plus a hand-curated abbreviation list covering TCE, PCE, BTEX, PFAS, Aroclors, and dioxin congeners) resolves lab shorthand to the right analyte. Once an analyte exists, the matching dictionary entries are attached to it as ordered aliases, so search and identifier resolution pick up common lab shorthand automatically.

concentration, concentration_numeric, and concentration_unit are the as-reported columns on a result. Canonical-unit derivation (see Canonical Concentration Unit) is additive: it writes separate provenance columns alongside the original value rather than rewriting it. A result questioned years later can always be traced back to exactly what the lab sent, independent of any conversion logic that ran on top of it.

In the GIS/Key 3.1 field spec, LAB_CAS_ID (#31) is the CAS number the lab assigns to a constituent; CAS_NUM (#32) is the CAS number CHEMDAS resolves against its own compound reference. Either LAB_CAS_ID or LAB_CHEM (the lab-reported name) must be present for a result to identify its analyte. The analyte synonym dictionary is itself CAS-keyed, so CAS number is the anchor both the GIS/Key format and the alias-resolution pipeline resolve around.

During the Standardize step, CHEMDAS derives a canonical unit and an exact conversion factor for every incoming result by applying a versioned conversion registry to the as-reported unit. Each result is stamped with its canonical unit, the exact conversion factor, the registry version that produced it, and a conversion status — converted, canonicalized casing, unconvertible passthrough, or unknown unit. Conversions requiring molecular-weight or temperature/pressure math (e.g. ppbv → ug/m3) are explicitly deferred: those rows are carried through unchanged with a factor of 1.0 and surfaced for review rather than silently converted.

Every uploaded file gets a SHA-256 content hash at upload time. Every audit-log entry is chained to the previous entry via record_hash/previous_hash (also SHA-256), append-only — save() and delete() throw on existing audit records. This lets any committed result be traced back to the original lab deliverable it came from, with a full record of corrections, warnings, and human decisions along the way. Separately, CUSTODY (field #66 in the GIS/Key spec) is the lab-supplied Chain of Custody ID that associates Travel Blanks with their Primary results — a narrower, format-specific use of the same term.

Both GIS/Key 3.1 import formats — Historical and EDD — read .dbf files exclusively. A GIS/Key export is a directory of related DBF tables (CResult, CTest, Surrog, Spike, and others) whose meaning is encoded by which file a row appears in as much as by any column inside it — which is why reading the results file alone quietly loses the blanks, spikes, and duplicates that make the data defensible.

GIS/Key 3.1 Historical declares a dedicated duplicate_split_results type (CRESULTD.dbf — identical to CResult but without the DUP_RPD/SPLIT_RPD columns) and a duplicate_split_tests type. RPD itself (field #51) is the lab-specified or GIS/Build-calculated relative percent difference between a primary and its duplicate; DUP_RPD (#92) and SPLIT_RPD (#93) are the maximum-RPD goals against which that comparison is judged. CHEMDAS also computes a live, persist-nothing field-vs-lab RPD comparison for paired field and lab measurements, guarding unit mismatches and both-non-detect cases rather than fabricating a number.

The GIS/Key 3.1 EDD is one of CHEMDAS's three import formats: a single-file, DBF-based lab electronic data deliverable in the GIS/Key 3.1 layout, distinct from the multi-file GIS/Key 3.1 Historical format used for legacy database exports. Lab resubmissions under this format are treated as full replacements, unlike historical imports, which append-correct. CHEMDAS reads these three environmental data formats end-to-end; the EDD is the electronic-deliverable path among them.

GIS/Key 3.1 Historical declares a spike_results type (SPIKE.dbf) and a spike_definitions type (DSPIKE.dbf). RES_CODE patterns SL (Lab Matrix Spike) and SF (Field Matrix Spike) identify spike results; RECOVER (field #46) is the constituent recovery percentage the lab reports, bounded by B_RECOVER/E_RECOVER goal limits (#52–53). A matrix spike is chemically distinct from a Surrogate — a spike is added to a real sample matrix to test recovery in that matrix, where a surrogate is added to every sample to test extraction/analysis efficiency.

A measured value is more than a float: it is a number that carries how precisely it was measured. CHEMDAS derives a result's canonical-unit value together with its significant-figure count — read on demand from the verbatim as-reported string (see Significant Figures) — its canonical unit, and its unit-conversion status. Because an exact conversion factor neither adds nor removes precision, a value converted between units keeps the significant figures the lab originally reported: 5.0 mg/L (two significant figures) stays two significant figures as 5000 ug/L, never four. This travels alongside — never instead of — the plain numeric value the rest of the pipeline already uses.

Every result carries two distinct reporting thresholds: the Method Detection Limit (MDL) — the lowest concentration that can be reliably distinguished from zero — and the Practical Quantitation Limit (PQL), the lowest concentration that can be reported as a defensible number. CHEMDAS converts both into the same canonical unit as the concentration, applying the same frozen per-row conversion factor used for the result itself, so detection limits and detected values always stay comparable in one unit.

Non-detect status is derived on read, never stored as a separate flag: it is the union of the lab's own less-than flag (a leading "<") and any qualifier code defined as a non-detect in the qualifier dictionary — the U code, for example. The determination is resolved from a versioned qualifier dictionary at read time, and the as-reported values that produced it are never modified.

The qualifier dictionary is a versioned mapping of each code to its meaning: whether it marks a non-detect, a rejected result, an estimated value, blank contamination, or exclusion from analysis. U means not detected; J means detected but estimated; R means rejected and unusable (excluded from analysis everywhere — charts, AI detection counts, and statistics all apply the same validator-over-lab precedence, so a rejected result is never charted or counted inconsistently); B means detected in the associated blank; E means over calibration range, estimated; D means diluted. Compound codes like UJ are split and combined. Meaning is derived on read — the as-reported qualifier is never modified.

A lab-reported 5, 5.0, and 5.00 are the same number but not the same measurement: they claim one, two, and three significant figures of precision. Only the verbatim as-reported string preserves that distinction — the numeric companion floats all three to 5.0. CHEMDAS counts significant figures on read from that string, following ASTM E29: leading zeros never count, a decimal point makes trailing zeros significant, a bare integer's trailing zeros are ambiguous placeholders that do not, and scientific notation counts only its mantissa. The count is derived on demand and never stored, so correcting a value's string automatically corrects its precision everywhere. It drives two things: rendering a value at honest precision instead of collapsing a real sub-microgram result to "0", and keeping a floating-point rounding artifact at an exact regulatory boundary from flipping a Pass into a fabricated exceedance.

The GIS/Key field spec carries a dedicated SURROG_FLG (field #9, ChemDAS column is_surrogate) marking a result as a surrogate. GIS/Key 3.1 Historical declares three separate surrogate types — primary_surrogates and duplicate_surrogates (SURROG.dbf / SURROGD.dbf, sharing one column shape), blank_surrogates (SURROGB.dbf, keyed on BLANK_ID), and control_spike_surrogates (SURROGQ.dbf, keyed on LBATCH_ID) — plus a surrogate_definitions type (DSURROG.dbf). In the unified schema, surrogates collapse to an is_surrogate flag on the result rather than a separate table per QC class.