Three vendors already use decision lineage, and they use it for something else. Elixirdata frames it for auditors, AskElephant for revenue teams, Collibra as data lineage extended through the model into an agent’s output. All three record how a system reached a conclusion: the inputs, the policies, the reasoning, the outcome.
I have been using the term since April for the opposite direction. In a delivery pipeline the machine writes the code but does not make the decision that matters. A person accepts that code into production, and that acceptance is the record nobody keeps.
The Four Facts
Four facts, recorded for every change that reaches production, captured while they are still true.
Who or what generated it. Human, agent, or a mix of both, with tool and model identity when an agent was involved. Most teams can only answer this by asking the author, assuming you can find one.
What a human actually reviewed. Not that somebody approved it, but how deeply they looked: read line by line, sampled, delegated to the gate, or auto-approved under policy. Recorded as an explicit state rather than inferred later from how confident the approver sounded.
The blast radius. What the change can plausibly break, in the terms the business uses: data exposure, availability, money movement, compliance surface. Somebody spends ten seconds on that question before the merge instead of during the incident call.
The owner. The named person accepting the residual risk. Not the committer by default, and not “the team”.
What It Is Not
Not git blame. Blame tells you whose name is on a line, but not what that person understood when they put it there.
Not supply-chain provenance. SLSA and in-toto answer what produced an artifact and they answer it well, but they describe artifacts rather than decisions. An attestation can prove an agent built the binary without telling you whether anyone decided that was acceptable.
Not verification. Verification tells you the code is sound, in seconds, and it keeps improving, but it says nothing about who owns the outcome. I made that argument at length in Verification Is Not Accountability.
Not a compliance artifact, though it will end up in audits. It exists so the next postmortem has a chain of decisions to walk back. Incident review has always worked that way, and agents did not remove the decisions, they removed the record of them.
Keeping It Small
Four fields, not a taxonomy. Governance efforts tend to start with a reasonable list and arrive eighteen months later at a form nobody fills in honestly, and a record filled in dishonestly is worse than none.
Mechanically it stays small too. A git trailer or a CI annotation carries the generator. Review depth is a required field on the merge template with four permitted values. Blast radius comes from signals static analysis produces today. The owner is a name. A governance layer that needs its own product will lose to the pipeline every time.
Where the Record Lives
The merge path. Your pull request and the gate sitting on it are the only point every change passes through, and the only point that can stop something.
A wiki copy goes stale within a quarter, and a governance document nobody reads is stale on the day it is written. The record has to fall out of the pipeline that is running anyway. I have had to do the reconstruction version of this in a regulated programme, and it costs many times what capturing the same evidence in flight would have.
So your gate answers two questions instead of one. May this code proceed, and is the decision record complete for this class of change. Incomplete record, no merge.
Where to Start
Four moves, and none of them is a six-month programme.
Measure the gap on one change. Pick an agent-authored change that merged into a consequential path last month, then try to reconstruct the four facts. However long that takes is the gap, measured.
Define what review depth means. Not a policy document, a short list your teams will actually pick from: read line by line, sampled, delegated to the gate, auto-approved under policy. Four values, argued about once, then put in the merge template.
Use the blast-radius signals you have. Static analysis knows when a diff touches auth, data access or payment paths, so start with those three. A risk taxonomy can wait.
Decide who declares and who owns. These are different people more often than teams expect. Whoever reviewed declares the depth, and the owner accepts the residual risk.
Most organizations owe a version of this record under SOX change management, and enterprise customers ask for it before regulators do. The question is whether you capture it while it is true or reconstruct it afterwards at several times the cost.