AI Lineage and Control: Why Provenance Determines Authority

Lineage vs. Provenance: A Necessary Distinction

Provenance and lineage are related but distinct concepts. Data provenance answers a backward-looking question: where did this dataset come from? It identifies the source — whether the data was synthetically generated, curated from real-world sources, derived from another dataset, or assembled from multiple origins. Provenance is the origin story.

Data lineage extends provenance forward through time. It records not just where the data came from, but what happened to it: what preprocessing steps were applied, what schema transformations occurred, what versions exist, and — critically — what its state was at the precise moment it was certified. Lineage answers: "where did this come from, what is it now, and how do we know?"

This distinction matters for AI governance because the compliance question is typically not about the data's origin alone — it is about the data's state at the time of use. A dataset that was clean and compliant at source may have been transformed in ways that introduce bias or remove required attributes. Lineage, not just provenance, is the relevant record.

Data Lineage: The Foundation Layer

Data lineage is the first layer of AI lineage because all other governance artifacts depend on it. A model's behavior is determined by its training data. A decision's validity depends on the compliance of the data that trained the model that made the decision. If the data lineage record is absent or incomplete, the governance chain cannot be traced back to its foundation.

A complete data lineage record for an AI training dataset includes: the dataset's origin source with provenance documentation; a log of every transformation applied to the dataset with timestamps and transformation parameters; the SHA-256 fingerprint of the dataset at each major version; and the cryptographic certificate that records the dataset's final certified form. Each element is linked to the next, forming a chain that can be traversed from any point.

Cryptographic certification creates the fixed reference points that make the lineage chain verifiable. Without certification, the lineage record is a narrative that can be altered. With certification, each version of the dataset has a hash that is mathematically tied to its content — altering the dataset invalidates the hash, and invalidating the hash reveals the alteration.

Model Lineage: Connecting Training to Deployment

Model lineage records the relationship between a deployed model and its training history. A complete model lineage record includes: the model architecture specification; the training run parameters (hyperparameters, training duration, hardware configuration); the evaluation results against specified benchmarks; and the certified training dataset(s) used in the training run, referenced by their certificate hashes.

The reference to certified training datasets is the link that connects model lineage to data lineage. When a model card contains the certificate hash of its training dataset, the complete lineage chain from model to data is traversable. When an investigator reviews a deployed model, they can retrieve the training dataset certificate and verify that the data used to train the model was certified, compliant, and traceable to its origin.

Model lineage also serves a forward-looking function. When a model is retrained or fine-tuned, the new model's lineage record references the prior model as a starting point. This creates a lineage graph that captures the entire evolution of the AI system — from initial training through all subsequent updates. Each node in the graph is anchored to certified datasets; each edge records the training or fine-tuning operation. This directly addresses the AI Control Gap at the model layer.

Decision Lineage: Closing the Chain

Decision lineage is the final link: the record that connects an individual AI output to the model and certified dataset that produced it. A complete decision lineage record references the decision identifier, the model version identifier, the model's certified training dataset hash, and the inference timestamp. With this record, any decision can be traced to its complete upstream lineage.

Decision lineage is where governance authority becomes operational. When a regulator asks "on what data was this decision based?" the answer is not "our model was trained on a dataset that we believe was compliant." The answer is: "this decision was produced by model version X, which was trained on dataset Y, which carries certificate Z, which was signed by CertifiedData.io and can be verified at this endpoint." The authority for the claim is the cryptographic chain, not the organization's assertion.

This is why lineage determines authority. Organizations that can provide complete, cryptographically verifiable lineage for their AI decisions have genuine authority to assert compliance. Those that can only provide narrative accounts are asking for trust. In regulatory and legal contexts, trust is not sufficient. See the transparency registry for publicly published certified artifacts.

Trusting Assertions vs. Verifying Facts

The core distinction between organizations with full lineage and those without is the difference between asking stakeholders to trust assertions and giving stakeholders the ability to verify facts. "Our training data was compliant" is an assertion. A signed, publicly verifiable dataset certificate is a fact — a fact that any party with the public key can confirm independently.

Enterprise AI governance programs that aim for verification rather than assertion build lineage infrastructure first. They certify datasets before they train models. They record certified dataset hashes in training logs. They link decision records to model versions. They publish verification endpoints. Each step converts an assertion into a verifiable fact, and the accumulation of verifiable facts is the only foundation for genuine AI control.