Industrial Data Architecture
Trace Readings
Preserve history.

On this page
Keep readings unchanged; check which equipment and labels they originally described.
Historical attribution
Fowler's draft temporal patterns separate effective history from earlier knowledge. Kimball's historical versions align facts with contemporary descriptions.
- M1
- Day 1 to before 10: cabinet C7, North, signal DRY-T, sensor S4.
- M2
- Day 10 to before 20: C7, South, CAB-T, S4.
- M3
- Day 20 to before 30: C7, South, CAB-T, S9.
- Compare
- Same day 9 observation: today's M3 assigns South/S9; historical M1 assigns North/S4. Day 10 selects M2; day 20 selects M3.
Start included, end excluded is assumed. Observation ID, time, value and unit stay intact. Gaps, overlaps or unqualified boundaries mean unknown attribution. Custodians establish boundaries. Late corrections retain corrected history and earlier reports' bases. No trial occurred.
Archive continuity
A renamed trend can look continuous while concealing how its names changed. The AVEVA Historian guide describes the creating or sending application recreating a tag under a new name. Incoming data then uses that name; older data initially remains associated with the former name. Its rename utility can update earlier metadata names without changing their tag IDs.
- Names
- Compare earlier and later spellings.
- Archive IDs
- Check continuity independently.
- Source application
- Identify who created and sent the series.
This yields an archive-continuity finding, not proof that an instrument remained installed. A continuous display cannot establish replacement history or recover the original spelling by itself. The inspected December 2022 manual is readable, not established as latest. Its behavior is product specific; no local installation or successful migration is claimed. Request existing evidence rather than experimenting on the production archive.
Changed sources
Two source descriptions can disagree even when their names look convincing. Fierro and colleagues' Shepherding paper replaces an older source model with its newer revision before repeating reconciliation. Names and types supply candidate links. Validation examines the combined description for incompatible types or relationships; the prototype requests human disambiguation and retains those resolutions.
- Inputs
- Amber revision: fan. Violet revision: temperature sensor.
- Conflict
- Assumed disjoint types prohibit the combined entity.
- Unresolved
- Keep separate pending physical-association evidence.
A proposed factory review could inspect that rejected combination without merging live records. Recheck changed descriptions. This is a building-controls proof of concept from 2020, not factory validation. Source-read timestamps do not establish equipment effective dates. A logically valid graph does not establish physical truth. AI may organize candidates; it cannot settle the physical association.
Import fidelity
Before investigating a disputed mapping, check whether its export was read correctly. Shafranovich's CSV description treats spaces as field content. Quoted fields can contain commas and line breaks. Splitting every line at every comma can therefore create a different table from the one exported.
- Exported row
"Dryer, west",temperature- Correct fields
- Dryer, west / temperature: two fields.
- Naive split
- Three fragments: a false extra field.
For an authorized offline check, inspect the parsed field count and exact strings beside the original record. Include a quoted line break if the exporter permits it; screen line count alone is insufficient. Do not trim spaces silently to improve matching. This informational RFC describes a common format, not every vendor dialect. Establish the actual export convention before treating an apparent field change as a maintenance event.
Structured exports introduce a different ambiguity. Bray's JSON specification recommends unique member names within an object. With duplicates, receivers can retain the last value, reject the object or expose every pair. A successful parse does not necessarily mean that all receivers saw the same description.
Consider a hypothetical object containing the member name instrument twice, once with probe-old and once with probe-new. Its author has not unambiguously expressed a replacement. This is not two historical records merely because two values appear in the text. Inspect the original object before a parser discards the duplicate. Recommend rejecting this ambiguity in an offline mapping import and returning the source object for correction. Do not select the more plausible instrument. The specification supplies a representation warning, not evidence about which device was installed. No parser or plant export was tested; the proposed finding concerns duplicate member names, independently of the CSV field-boundary problem.
Label comparison
Two labels can look alike while containing different character sequences. Unicode's normalization annex distinguishes canonical equivalence from compatibility equivalence. Normalization creates a consistent representation for a specified class of equivalent text; compatibility normalization can also erase distinctions that matter.
- Original
- An accented label looks unchanged.
- Characters
- One precomposed character versus a base letter plus combining mark.
- Comparison
- Normalization Form C (NFC) can match canonical equivalents; retain received strings.
This is useful when a copied accented label fails an exact comparison despite looking unchanged. Conversely, compatibility folding may make previously distinct strings compare equal. Keep comparison output separate from the received identifier. Show the transformation instead of merely declaring a match. Normalized equality is a text finding, not a physical-identity decision. Do not overwrite production labels to make an offline comparison pass. The proposed view has not been implemented or tested.
A portable reference also needs its context. Berners-Lee and colleagues' URI syntax resolves relative references against a base address. A uniform resource identifier is a structured reference; a relative one is incomplete without that base. Copying a mapping document can change what its references resolve to if the original context is lost.
In an independent hypothetical export, points/probe under https://alpha.example/map/ resolves within alpha's map. Under https://beta.example/map/, the same text resolves within beta's map. These are illustrative reserved-domain addresses, not installed endpoints or links to visit. For a future comparison, show the received reference, declared base and resolved absolute reference together. If the original base is unknown, report the reference unresolved instead of borrowing the destination folder's base. This check concerns reference resolution, not whether either address describes real equipment. A syntactically complete address still needs evidence linking its resource to the intended observation.
Row multiplication
A join connects rows according to a matching rule. DuckDB's join documentation explains that a left outer join can retain unmatched input rows, using nulls for the missing side. Returning rows is therefore different from establishing one usable association per input.
- Inputs
- Two observations, A and B.
- Matches
- A has two candidates; B has none.
- Output
- A appears twice; B appears once with null mapping fields. Three rows represent two observations.
Here, output rows equal two plus one, not two successful assignments. Reconcile distinct observation identifiers as well as output row count. An inner join would drop B and return A twice: still two rows. A plausible total can hide both defects. Keep unpaired inputs visible; investigate multiply matched inputs before using the joined description. Cardinality means rows per input. This is not a temporal-boundary test; no query was run.
Reviewable edits
An exported mapping can differ as text without changing its object properties. Rundgren and colleagues' canonicalization scheme specifies deterministic property sorting and serialization for constrained JSON data. Canonicalization means choosing one prescribed representation, rather than accepting whichever formatting a writer happened to emit.
For an independent hypothetical comparison, an object listing label before asset and one listing asset before label can have the same canonical representation when their values agree. Reversing elements within an array does not receive the same treatment: array order is preserved. An offline reviewer could distinguish a formatting-only export from a changed ordered list before reading a long diff. Keep the original files alongside that comparison. This informational scheme does not validate the mapping's physical meaning, and no canonicalization tool was run. A clean canonical comparison supports a narrow representation finding; it does not establish that an instrument, location or effective boundary was correct.
Finally, a proposed correction must identify the document it was prepared against. Bryan and Nottingham's JSON Patch defines a test operation that checks a specified value. An unsuccessful operation means the patch must not be deemed successful. That supplies a precise precondition, rather than a request to trust an editor's memory.
- Expected revisionEditor prepared against revision blue.
- Received revisionCurrent document says green.
- ResultTest fails; reread and revise the proposal.
Put such a check before proposed changes, and require the surrounding application to handle unsuccessful evaluation correctly. A revision value must actually track relevant edits to serve this purpose. Passing the test says only that its precondition matched; it grants no equipment permission and establishes no physical fact. Return a stale proposal with its disagreement visible instead of presenting it as an applied correction. No patch, historian edit or live control action occurred.
Sources and further guidance
References checked October 26, 2026.