Lineage You Can Actually Defend

In "Speed Is Not a Strategy" I laid out four decisions every organisation needs to make before scaling AI: what the data is licensed to do, whether the lineage is provable, who owns a model's failure, and what the exit path looks like. In Post 2 I covered the first, whether your data was ever licensed to do what you are now asking it to do. The second decision assumes you cleared that bar. It asks something harder. Even where the data is properly licensed, can you actually prove where it came from and what happened to it on the way to the model?

A Wiki Page Is Not Lineage

Most organisations, if pressed, can produce something that looks like lineage documentation. A diagram in Confluence. A spreadsheet someone maintained for a while and then stopped. A verbal explanation from the one engineer who remembers how the pipeline was built three years ago.

None of that survives contact with a regulator, an auditor, or a breach investigation. Those all ask the same question in different forms: show me, not tell me. A wiki page is a claim. Lineage is evidence.

What Auditable Actually Means

Auditable lineage has three properties a diagram does not:

• It is generated, not maintained. If lineage depends on someone remembering to update a document every time a pipeline changes, it will be wrong by the time you need it. Auditable lineage is captured automatically as data moves and transforms, tied to the pipeline itself rather than a separate record someone has to keep in sync.

• It survives the question you did not expect. Real audits do not ask "where did this data come from" in the abstract. They ask "was this specific field, for this specific customer, derived from a source that had consent for this use, as of this date." If your lineage cannot answer at that level of granularity, it cannot answer the question that actually gets asked.

• It covers transformation, not just origin. Knowing a dataset originated from a CRM system is a start. Knowing what happened to it between the CRM and the training set, what was joined, filtered, aggregated, or derived, is what actually matters when something goes wrong and you need to trace why.

Where Lineage Tooling Fits, and Where It Doesn't

Lineage tooling helps, but it is not the whole answer. A catalog or lineage graph can capture technical lineage, table A fed table B, which in turn fed the training set, reliably and automatically. What it cannot capture on its own is the governance context: whether the use was licensed, who approved it, and under what conditions. Technical lineage without governance lineage tells you what happened. It does not tell you whether it should have happened.

The practical answer is to treat lineage as two layers that need to connect: the automated technical trace, and the governance decisions from Post 2 attached to it at the point of use. Neither layer alone is defensible on its own.

What to Do When Lineage Is Already Broken

Most organisations are not starting with a clean slate. Legacy pipelines exist that nobody fully documented, and going back to reconstruct lineage for every historical dataset is not realistic. The practical approach is triage, not completeness. Prioritise lineage reconstruction for the datasets feeding your highest-risk AI use cases first, the ones touching sensitive categories, the ones influencing decisions about individuals, the ones a regulator would ask about first. Accept that some historical gaps will remain, and be honest about that gap rather than papering over it with a diagram that implies more certainty than you have.

Where This Leaves You

If a regulator, a customer, or a board member asks where a piece of training data came from and what happened to it, the answer needs to be ready, not reconstructed under pressure. That readiness is the second decision in the framework, and it is usually the one organisations discover they are furthest behind on.

The third decision assumes the first two are solid and asks what happens anyway when the model gets something wrong. Who notices, who acts, and who has the authority to pull the plug. That is failure mode ownership, and it is where accountability either holds or quietly evaporates.