Model Lineage Answers 'Which Model.' Your Auditor Asks 'What Did You Do.'

Give the ML platforms their due. Feature stores, model registries, and end-to-end lineage genuinely make a model reproducible: you can pin the training data, the feature transformations, the hyperparameters, and the exact version alias that served a request. Inference tables capture inputs and outputs at scale. Drift and quality monitoring catch a model degrading in production, and the newer agent-evaluation harnesses — judge models scoring factuality, accuracy, and cost — put real numbers on model behavior. The most advanced AI gateways go further still: they govern the model call itself, applying rate limits, guardrails, credential management, and inference logging even to agents running off the platform.

This is not a strawman, and none of it is going away. It makes the model reproducible and the call observable. But read the artifact it produces closely and you find it answers one family of questions — which model, which version, which features, which score, called how often, within which guardrails — with real rigor. It is a complete account of the model, and of the request made to it. It is silent on the sentence that follows.

A model returns a prediction. Nothing has happened yet. The event that carries legal and financial weight is the action your enterprise takes on that prediction: the loan declined, the payment released, the transaction posted, the claim routed to fast-track, the customer's plan downgraded. That action is what a regulator examines, what an incident review reconstructs, and what an adverse-action complaint disputes.

And the question they ask has a specific shape. Not "which model version scored this applicant," but: what action was taken on that score, under which policy in force at that moment, by which identity — human or agent — and can it be reversed? A declined applicant is owed specific reasons for the decision, not a model card. An incident review needs to know which automated actions fired and on whose authority. Model lineage, however faithful, is the wrong shape for this question. It documents the input to the decision, not the decision.

The gap is a schema gap, and naming it makes it concrete. Per-model lineage is keyed on the model: version, training set, feature vector, score, drift over time. It is organized around the artifact. What an auditor needs is per-action provenance, keyed on the act: input, prediction, policy evaluated, action taken, actor, outcome, reversibility. One is a biography of the model; the other is a record of a thing that was done to a customer or to a ledger.

You cannot derive the second from the first, because most of its columns — the policy that was in force, the identity that committed the act, the downstream state that changed — never enter the model's world at all. They live in whatever system actually took the action.

The category's answer to this is reconstruction. The agent-governance vendors promise to rebuild the decision path from telemetry — every inference and tool call streamed into a central analytical store as queryable SQL tables, ready to be joined after the fact. It is genuinely useful engineering, and for the calls it observes, it is a real audit trail of the call. But three structural problems keep it from being a record of the action.

• It is a join, not a record. The provenance is assembled after the fact by correlating inference logs with downstream tool-call logs kept in separate systems, across trust boundaries. Its integrity depends on every intermediate system having logged faithfully, on clocks agreeing, and on the correlation keys lining up. A reconstruction is an inference about what happened; it carries the evidentiary weight of a reconstruction, not of the act.
• The gateway governs the call, not the commit. Even the most advanced gateway is a governed proxy sitting in front of model-serving. It governs the inference request and the tool invocation and captures them — but the business action the prediction drives commits in a system of record the gateway sits beside, not inside. It sees the API call go out; it does not hold the transaction that posts.
• It cannot capture what it never saw. An action taken through a path the platform never brokered — a shadow execution path — leaves no row to join. The join is only as complete as the instrumentation, and the one action most worth auditing is often the one that ran around it.

Each problem is survivable on its own. Together they mean the reconstructed decision path is at best a high-quality estimate of what happened, produced by a system that governed the model's call and inferred the rest. That is a fine debugging tool. It is a shaky footing for the sentence "here is the complete, tamper-evident record of every action this model drove, and who was accountable for each."

This is not a hypothetical bar. Model-risk guidance in the mold of SR 11-7 has never been only about model development; it treats model use and implementation controls as first-class — the controls around how a model's output is consumed and acted upon, and the outcomes analysis that follows. Decision-level accountability regimes go further: the newer AI regulation attaches record-keeping, human-oversight, and traceability obligations to the high-risk decision the system makes, not merely to the model that informed it.

Consider the most concrete version. An applicant is declined; the law entitles them to the specific principal reasons for that decision. What discharges the obligation is not the model's feature-importance chart but the record of the action — the reasons in force at the moment of denial, tied to the policy applied and the identity that committed it. Per-model lineage supplies the raw ingredient and stops there; the accountable fact lives one system over.

Against that bar, a per-model lineage graph plus a post-hoc telemetry join is structurally short. It documents the model rigorously, reconstructs the action approximately, and goes dark exactly where an action took a path the platform never observed. For an examiner asking "show me every automated adverse action this quarter, the policy each ran under, and who authorized it," a reassembled trace is an argument you make about the evidence. It is not the ledger.

Entroid closes the gap by changing where the model sits. Architecturally, it is not an endpoint the process calls out to; it runs as a governed Function inside a Deterministic Workflow on a single runtime. The prediction is consumed, in the same executing process, by the workflow step that acts on it — and that step is where the inline controls live: the approval gate, the threshold, the separation-of-duties check, the human-in-the-loop pause that is a first-class primitive rather than a bolt-on. The only primitive that touches an external system is a governed Connector, so the act of committing — posting the entry, releasing the payment — happens under the same governance as the prediction that triggered it.

Because prediction and action share one transaction boundary, the provenance record is not assembled later; by design it is emitted as a byproduct of execution — input, prediction, policy evaluated, action taken, actor, outcome — in one immutable per-action record, explainable by construction. There is no shadow path to miss, because the action does not commit except through the governed step. This is a property of the design, not a dashboard bolted over it: the audit and the execution are the same event.

Be clear about what this is and is not. ES does not levitate above your estate — it runs over your existing systems through those governed Connectors, so the integration work is real and the fabric earns its place one connected system at a time. What changes is architectural: the model and the action it drives stop living in two systems stitched together after the fact, and start living in one governed process whose audit is its execution. The MLOps stack is built to answer "which model." ES is built to answer "what did you do."