Data Lineage and Governance

Every signal, feature, model, and decision carries provenance — so the plant can prove, after the fact, exactly what any action was based on.

Provenance as a first-class requirement

In an AI-native plant, trust in a decision depends on trust in the data behind it. The architecture tracks lineage from the first sample: which sensor, which calibration, which validation status, which feature transform, which model version, and which twin state fed each decision. Governance is not a report; it is a property of the data fabric.

What lineage covers

• Signal — sensor identity, calibration, and validation status at ingest.
• Feature — the transforms applied and the feature-store version served.
• Model — which trained model, trained on which data, promoted by which validation.
• Decision — the command issued, the twin state it used, and the human confirmation if any.

Why it matters for safety and honesty

Lineage is what makes the honest gates enforceable. Because every result carries whether it came from measurement or simulation, a copilot cannot present a simulated equilibrium as a measured one, and an audit can always distinguish the two. Before FOAK, that distinction is the difference between a design claim and a data claim.

Governance and IT/OT separation

Governance also spans the security boundary. The operational-technology side is isolated from general IT by airgaps and unidirectional data diodes, so telemetry can flow out for analysis while nothing can flow in to the control path uninvited. The gray IT/OT line in the blueprint marks exactly this boundary, and lineage records every crossing.

Lineage is a purple governance function; it underwrites the honest gates and the retraining loop.