Engineering Journal
Table Formatter
Table Formatter

Your AI pipeline's provenance should never record which model spoke

2026-07-23

TLDR: The instinct in AI systems is to make lineage mean "which model said this, from what prompt." For a pipeline whose output has to be trusted, that is backwards. The model is a driver that calls deterministic tools; the tools produce the values. Put the tools in the lineage and keep the model out of it.

The position

In a pipeline where correctness matters, every derived value should carry a record of which deterministic tool or stage produced it, from what source, through what transformations, at what confidence. That record should contain no reference to a model. The AI is the thing that decided which tool to call. It is never the thing that produced the value, so it never belongs in the value's history.

This is the opposite of where most AI tooling is heading, which is toward logging the model, the prompt, and the completion as the primary record of how an output came to be.

What the industry does, and why

The dominant pattern is LLM observability: capture the prompt, the response, the model version, the tokens, the latency. Attach it to the output so you can trace what happened. It is a reasonable instinct, because in a naive AI app the model genuinely is the worker, it wrote the answer, so logging the model is logging the author.

Vendors have built whole products around this, and for chat-style systems it is the right lens. If the model produced the text, you want to know which model and which prompt.

Why it fails for this problem class

An auditable pipeline is not a chat app. Its value is not that a model generated something plausible; its value is that a chain of deterministic tools produced a result you can verify. The model's role is orchestration: it decides to extract this table, validate that column, compute this node. But the extraction, the validation, the computation are done by tools whose behavior is fixed and checkable.

If your lineage says "GPT produced this value," it is lying, because a model did not produce the value, a deterministic extractor did. Worse, "the model said so" is not auditable in the way that matters. You cannot re-run a model and get the same output, and "trust me, the model was confident" is not evidence. The whole point of provenance is to answer "why should I believe this value," and a model reference cannot answer that.

There is also a durability problem. Model-centric lineage rots every time you swap models. Tool-centric lineage does not, because the tools are stable. A better model just means better decisions about which tools to call; the attribution chain stays meaningful.

The better approach

Record deterministic tool attribution. Each value's history is a chain of tool handoffs: this extractor pulled it from this source region at this confidence, this validator checked it and raised its confidence, this stage computed the result. Each tool self-reports its contribution as it touches the value. The model is absent from the record entirely.

Concretely, a lineage entry names a tool, a stage, the operations applied, and a score, and stitches to the entry before it. Read the chain end to end and you get a verifiable story: extracted (score X) then validated (score Y) then computed (per this rule). Every link is a deterministic operation you can re-run and check. That is auditability.

The model still drives all of it. It just does its driving above the lineage, not inside it.

What you give up

You lose the ability to answer "which prompt produced this" from the lineage, because it is not there. If you are debugging the orchestration itself, you do want model logs, so keep them, but keep them in a separate observability channel, not fused into the value's provenance. Mixing the two is what corrupts the audit trail.

You also take on discipline: every tool must self-report honestly, and every handoff must append its link. That is real work, and a pipeline where one tool skips it has a gap in the chain.

When the common pattern is right

If you are building a chat assistant, a content generator, or anything where the model's output is the product and a human reviews it, log the model. There the model is the author and model-centric observability is exactly right.

The tool-attribution model earns its place when the output must be trusted without a human redoing the work, and when "a model was confident" is not an acceptable answer to "why is this correct." In that world, the model is a driver, the tools are the workers, and the lineage is a record of work, not a record of what the model happened to say.

The one line

Provenance answers "why should I trust this value." A model reference cannot answer that, because you cannot re-run it and it did not produce the value. Record the deterministic tools that did, keep the model out of the chain, and your lineage stays both truthful and durable across every model you will ever swap in.

Read this post in the full Engineering Journal →