BLUF: Store whether a temperature feature represents a reading, a difference or a gradient before converting its unit. Absolute Celsius and Fahrenheit readings need an offset; temperature differences do not. A dimensionally valid Kelvin value can still represent the wrong quantity. Bind quantity kind to a versioned feature contract, preserve the raw observation and test conversion rules against independent reference values before inference.
An executed synthetic fixture using Python 3.12.13 and Pint 0.25.2 passed ten numerical checks, rejected eight invalid operations or inputs, and detected three deliberately wrong converters with reference assertions. These are local software results, not evidence of calibrated instruments, improved maintenance accuracy or safe equipment settings. The example remains on an advisory data path.
The error that a numeric schema does not see
Consider a bearing-temperature reading and its rise above a reference sensor. Both arrive as numbers associated with temperature. The first describes a point on a scale; the second describes a separation between points. Adding the Celsius-to-Kelvin offset to the rise invents a different feature while preserving a plausible numeric type and temperature dimension.
In this article, “absolute reading” means a temperature point, including a reading expressed in Celsius. It does not mean Celsius is an absolute thermodynamic scale. The distinction is between point and difference semantics, not a claim that a sensor measures perfectly.
The industrial data-contract foundation establishes asset identity, units, quality and ownership. This implementation goes deeper into one conversion boundary: may the adapter apply an affine transformation, or only a scale factor? It does not replace that broader contract.
The decision matrix: choose meaning before unit
| Quantity kind | Conversion | Required contract |
|---|---|---|
| Absolute reading | Scale plus offset | Temperature point; source scale |
| Temperature difference | Scale only | Reference and subtraction meaning |
| Spatial gradient | Difference scale per length | Denominator unit and direction |
| Kelvin input | Numeric identity can be valid | Keep absolute versus delta kind |
For absolute readings, T_K = T_C + 273.15 and T_K = (T_F − 32) × 5/9 + 273.15. For differences, ΔT_K = ΔT_C = ΔT_F × 5/9. A spatial gradient uses the difference scale per length, for example K/m. A temporal heating rate uses time instead; these dimensions must not be interchanged.
The Pint temperature documentation for the tested release explicitly distinguishes offset units and delta units. Construct an absolute reading with Quantity(25, 'degC'), not 25 * ureg.degC under the default strict configuration. Subtracting two Celsius readings produces a delta quantity. Keep autoconvert_offset_to_baseunit=False so ambiguous offset operations are not silently relaxed.
Pint's parser can interpret degC/meter as a delta unit in a multiplicative context. That convenience is not permission to infer the producer's meaning from a string. In the fixture, a declared gradient maps explicitly to delta_degC/meter or delta_degF/meter, with meter fixed by the test contract. A production gradient must also carry its denominator unit and physical direction. Do not append “/meter” to an unspecified source measurement.
Keep the unit namespace and quantity kind separate
UCUM defines machine-readable unit expressions, including special units on non-ratio scales. Its case-sensitive temperature tokens include Cel, [degF] and K. Pint names such as degC and delta_degC are library identifiers, not a claim of UCUM serialization. The example uses an explicit three-token application allowlist; it is not a general UCUM parser or a full-conformance implementation.
A record's kind is separate application metadata: absolute, delta or gradient. For a delta tagged with the source scale Cel, the adapter selects Pint's delta_degC. That pairing is a documented application contract, not a new UCUM delta token. Reject unknown tokens rather than guessing from a localized display label. Preserve the original spelling and namespace for diagnostics.
The OPC UA engineering-unit specification explains that EUInformation.namespaceUri identifies the unit system; the default mapping is UN/CEFACT, not UCUM. Retain namespaceUri and unitId together. An integration that converts them to UCUM needs a versioned mapping, not an assumption that displayName is already a UCUM code. Preserve raw StatusCode and timestamps independently; engineering-unit information does not certify quality or calibration.
Lineage: never overwrite the evidence
At ingestion, retain raw value and unit token, namespace and identifier, asset and sensor identity, source timestamp, raw quality, quantity kind, calibration reference and acquisition context. At the contract boundary, compare the declared kind with the consumer feature definition. At conversion, add canonical value and unit, conversion-rule version and source-record reference. At feature assembly, retain the derivation and input references rather than overwriting the original observation.
The executed fixture preserves its raw record, a synthetic calibration marker, normalized flag and temperature-v1 rule. It deliberately rejects a second normalization. This catches a common pipeline wiring error; it is not a distributed exactly-once protocol. A production replay should use immutable raw events and deterministic output keys, or return the already-derived result only after checking its provenance and rule version. Never reuse a normalized magnitude while relabelling it as raw Celsius.
Calibration provenance is a reference to evidence, not a boolean promise. The fixture's synthetic-not-calibrated marker makes its limitation explicit. Instrument replacement, changed scaling in a transmitter or a calibration revision can require a new mapping version even when the engineering unit remains unchanged.
Executed reference tests and deliberate faults
| Synthetic input | Canonical result | Wrong rule to detect |
|---|---|---|
| 25 degC absolute | 298.15 K | Omitting offset gives 25 K |
| 77 degF absolute | 298.15 K (rounded) | Scaling without reference shift |
| 10 delta_degC | 10 K difference | Adding offset gives 283.15 K |
| 18 delta_degF | 10 K difference | Absolute conversion gives 265.372222 K |
| 2 delta_degC/m | 2 K/m | Adding an absolute offset |
| 3.6 delta_degF/m | 2 K/m | Ignoring Fahrenheit scale |
The ten positive checks cover three absolute scales, three difference scales, two spatial gradients, subtraction of readings and a round trip. The Fahrenheit absolute result was 298.15000000000003 K in binary floating point; the independent reference was 298.15 K. Comparisons used zero relative tolerance and 1e-9 absolute tolerance. That is a numerical regression tolerance for generated values, not a permissible sensor error or alarm deadband.
The eight rejected cases were absolute-to-delta and delta-to-absolute contract swaps, an unknown unit token, an incompatible dimension, repeated normalization, Bad quality, NaN and ambiguous multiplication of an offset unit. Quality is deliberately simplified to an exact Good marker in this fixture; a real OPC UA adapter needs a reviewed StatusCode mapping rather than this string shortcut.
The three deliberately wrong converters applied an offset to a Celsius difference, omitted the offset from a Celsius reading, or applied an absolute Fahrenheit conversion to a difference. All failed their independent numeric reference assertions. A round trip alone would be insufficient: two mutually consistent wrong mappings can undo each other. Include externally specified anchors as well as round trips and boundary tests.
One intentional limitation also passed through the fixture: a value labelled delta in Kelvin is accepted when the consumer contract also expects delta, even if the producer secretly meant an absolute reading. No dimensional library can reconstruct that missing intent. Validate producer semantics with instrumentation documentation, known reference observations and an accountable data owner. This gate detects disagreement; it cannot prove a mutually wrong declaration true.
Implement the gate without hiding operational costs
1. Inventory one feature family. Separate raw readings, cross-sensor differences, deviations from baselines, spatial gradients and temporal rates. Name the reference sensor, time alignment and baseline revision wherever subtraction is involved.
2. Freeze a reviewed source-to-library mapping. Bind namespace, identifier, quantity kind, denominator units and canonical output to a version. Construct the unit registry once per worker; do not rebuild it for every event. Benchmark your actual adapter before claiming throughput or latency improvements.
3. Reject missing semantics, unsupported mappings and unusable quality before conversion. Quarantine a bounded evidence sample with reason codes and count all rejected records. Strict rejection reduces feature availability; do not compensate by silently guessing units.
4. Run independent anchor tests and mutations in CI for every mapping change. Pin Pint and retain the dependency lock, reference values, tolerances and test output. Add deployment-specific tests for decimal precision, extreme values, namespace changes, restart replay and vectorized batches; this scalar fixture does not exercise those paths.
5. Replay training and serving features through the same contract version. A corrected conversion can shift a learned feature distribution, so compare downstream task behavior and retrain or migrate explicitly where necessary. Keep old versions replayable for incident analysis.
6. Keep missingness and sampling controls independent. Bounded sensor imputation governs whether an absent observation can be substituted; anti-aliasing before downsampling governs retained signal bandwidth. A correctly converted number can still be imputed too long, temporally misaligned or aliased.
What to review before connecting this to a model
The cost is maintaining semantic mappings, calibration references, replayable versions and quarantine ownership. Library checks add work, but the larger operational risk is changing feature meaning without coordinating consumers. Unit conversion cannot establish engineering validity, sensor calibration, functional safety or permitted alarm thresholds. Equipment settings remain outside this example.
For an implementation review, bring one temperature feature definition, the producer's unit and quality metadata, calibration references and a small read-only sample. I can help turn these into a versioned conversion contract and executable rejection tests. The first useful deliverable is a traceable answer to what each number means—not another model trained on an ambiguous column.
