Lineage and provenance: the trail that has to exist already

Provenance answers where data came from and whether you are allowed to use it. Lineage answers how a particular number in front of a particular customer came to be. They are different problems with different owners, and both are cheap to build forward and impossible to build backward.

What lineage has to connect

The chain that matters runs: source system, extract, dataset version, feature transformation, model version, deployed configuration, decision, output shown to a person. Any break in that chain and a complaint about a decision made eleven months ago cannot be answered, whatever the model documentation says.

The link most often missing is between the deployed model version and the dataset versions behind it. Model registries record the model. Data platforms record the data. Very few organisations record the join, and it is the join that an investigator needs. Make it a release artefact: a model cannot be promoted without recording the dataset versions, the feature definitions and the configuration it was built from.

The second most common break is configuration. The model did not change, but a threshold was retuned in a config file by someone responding to an alert volume complaint, and that change is not versioned with anything. For a scored decision, the threshold is as consequential as the model.

Provenance beyond your own boundary

A fine-tuned open-weight model inherits every provenance question of its base model. You did not create those questions and you cannot answer them, but they are in your system. Record what the provider discloses and record explicitly what they do not, with the date you asked. An unanswered question is a finding, not a blank.

The fields worth carrying per dataset are the sources or owners including scraped and purchased data; whether the data was purchased or licensed and any restriction attached; whether it contains material protected by copyright, trademark or patent or is public domain; whether it contains personal information; the number and types of data points and the labels used; the preparation operations applied; the collection period and whether collection is ongoing; and whether synthetic data was used. That list is deliberately the union of Article 10 and the California disclosures, so one record serves both.

Retention outlives the system

Articles 19 and 26(6) require logs to be retained at least six months, by providers and deployers respectively, subject to data protection law. Colorado SB 26-189 requires records demonstrating compliance for at least three years. Those periods run past the life of many models, which is why the decommissioning record exists: a system switched off last year can still be the subject of a complaint, and deleting the register entry removes your own ability to show what you once ran.

Both failure directions are real. Deleting everything at shutdown destroys the ability to answer. Keeping everything forever, especially personal data in logs, converts a compliance control into an open-ended data protection exposure. Decide per artefact, in writing, before the system goes off.

Worked example: a reinsurer reconstructs one decision

A reinsurer is asked by a cedant to explain why a facultative submission was scored as it was, fourteen months earlier. This is the test the lineage record exists for, and it is worth running as a drill before it arrives for real.

The team can retrieve the submission, the output score and the underwriter's final decision, because those are in the transaction store. They cannot immediately retrieve the model version, because the scoring service records a model name and not a version hash, and the name has been reused across three releases. They eventually identify the version from deployment logs, which are retained for ninety days for operational reasons and happened to still hold the relevant window by luck rather than design.

Three fixes follow, all prospective and all cheap. The scoring service writes an immutable model version identifier and a configuration hash into every decision record. Deployment log retention is aligned to the statutory floor rather than to an infrastructure default, with a deliberate decision rather than an inherited one. And the release process refuses to promote a model that does not declare the dataset versions it was trained on.

The fourth fix is the drill itself. Once a quarter, someone picks a decision at random and reconstructs it end to end, and the result is recorded whether or not it succeeded. That test is the only way to know the specification works, and it is the item auditors respond to most strongly, because it shows a control being exercised rather than described.

As of 24 September 2026.