Execution lineage vs data lineage: why data origin can't explain an AI decision

Every field had a source. The denial had no explanation.

An insurer uses an AI application to assess complex reimbursement claims. A claimant challenges a denial and asks why.

The data team answers confidently. Their lineage graph shows the claimed amount came from page three of the invoice, the coverage limit from the policy system, the prior-claim count from the claims warehouse, and the risk score from a versioned transformation. Every field traces cleanly to its source.

Then the harder questions arrive. Why was one policy amendment used and another excluded as stale? How did the model's "mismatch score" turn into the facts the policy rule checked? Policy required specialist review, but did that requirement reach the reviewer? The approval system says approved = true, but which version of the denial did the reviewer see? The case waited overnight while the claim and the policy bundle changed. Was anything rechecked before the denial went out? And the claims system shows a denial notice was issued, but nothing ties it back to the authority, proposal and approval behind it.

That's not a failure of data lineage. It's asking data lineage to answer a bigger question than it was built for.

Data lineage is indispensable

Data lineage records where information came from, how it moved and changed, which versions were involved, and what was derived from it. In AI applications it connects source records to extracted fields, document chunks, embeddings, feature values and model inputs. It powers data quality, change impact, debugging, stewardship and regulatory response.

Most lineage tools focus on datasets, tables, columns, files, documents and features; on pipelines, queries and transformations; and on ownership and classification. That's essential. It's one part of the application's history, not the whole of it.

General provenance models are broader than most implementations. W3C PROV can describe entities, activities and agents, including who acted on whose behalf. The gap is usually scope, not the standard.

What's the difference between data lineage and execution lineage?

Data lineage explains the history of information. Execution lineage explains the history of application behavior: how that information was selected, decided on, authorized, approved and turned into a real change.

Execution lineage doesn't replace data lineage. It references it, and adds the application meaning around it.

Seven domains, one run

An application run draws on several kinds of record, each with its own owner and rules:

Execution lineage is the set of links that ties these to the same run.

Context is selected, not just sourced

Retrieval adds a selection step between stored information and the model. The application might start with thousands of candidate documents and build a small context package through filtering, ranking, chunking, summarizing and token limits. Source lineage tells you which document a chunk came from. The application record also needs which access and freshness rules applied, which candidates were filtered out, what was summarized or truncated, and exactly what the model received. (See context provenance.)

There's an honest limit here. Lineage can prove what information was allowed, selected and supplied to a model, and what came back. It shouldn't claim to reveal the model's internal reasoning.

Why can't data lineage show whether an AI action was allowed?

Because the same data can lead to different legitimate outcomes for different users, purposes, entities, record states or policy versions. Data origin says nothing about whether a specific action was permitted.

That's why execution lineage joins identity and delegation, scope and purpose, the policy version and its obligations, how the decision was enforced, and the human approval. With those links, investigators can tell apart outcomes that look identical in data lineage:

Lineage has to cover time and waits

AI work is often long-running. Cases wait for people, events, timers and external systems, and the world changes meanwhile: a policy is updated, a record is edited, a reviewer loses authority, a proposal is recalculated. Each step needs a link to the workflow version, the record revisions, the wait and what resumed it, and whatever was rechecked at resume. Without that, you know which data revision was used but not which rules and current state governed the action.

Where should lineage end?

At the business effect. A lineage record is incomplete if it explains the information and the decision but can't identify what actually changed in the system of record, or prove that nothing did.

Many efforts stop at the model output or the API request. The outcome happens after that. A consequential record continues through the proposed action, the authorization to run it, one stable operation ID with its individual attempts, any timeout or uncertain result, and the confirmation or reconciliation from the target system. That's how you show the real effect matched what data, policy and the reviewer authorized. (See retries and idempotency.)

Connect existing systems; don't replace them

You probably already have authoritative records for data transformations, documents, features, model and prompt registries, identity and policy decisions, approvals, traces and external receipts. Don't copy all of them into one giant store to claim completeness. That blurs ownership, retention and access.

Instead, link them. Use stable identifiers, versions and digests so each system stays the authority for its own records, and the application record ties them to the same run, proposal, decision, approval and effect. Provenance standards already support specializing generic relationships and linking provenance across sources.

Lineage needs permission-aware views

A complete record can reference more sensitive material than the outcome itself: restricted documents, rejected candidates, personal identities, policy attributes, prompts, reviewer comments and API arguments. Don't make it universally visible. Keep one record and give each role an appropriate view: data owners see sources and use; developers see paths, versions and errors; security sees authority, scope and enforcement; auditors see proposals, policy, approvals and confirmations; business owners see the decision path and outcome; operations sees waits, retries and failures.

The same record also underpins replay. Running today's model and policy on yesterday's data is a useful comparison, but it isn't a reconstruction of what happened unless the past versions are restored too.

Common anti-patterns

Ten rules for execution lineage

1. Keep data lineage; make it one part of the application record.
2. Anchor lineage to the workflow version and the specific run.
3. Give context, proposals, decisions, approvals, operations and attempts their own IDs.
4. Record explicit links; don't infer meaning from timestamps.
5. Connect context to decisions, authority, policy, approvals and effects.
6. Bind every run to the model, prompt, policy and schema versions it used.
7. Continue until the system of record confirms the effect, or confirms none.
8. Link authoritative systems instead of copying them.
9. Decide lineage coverage, retention and views before you deploy.
10. Use the same record for explanation, audit, investigation and replay.

The result: a complete account of the outcome

Data lineage remains one of the most important foundations of enterprise AI. But an AI outcome isn't produced by data alone. It comes from data moving through an application shaped by identity, policy, versions, waits, human judgment and external systems.

Execution lineage is the record of that larger behavior. It gives data lineage a place inside the full explanation, so when a claimant, auditor or regulator asks why, you can show not only where the evidence came from, but how it became the decision.