Tracing one business fact from source system to agent action

AI data lineage becomes harder at the point where a business fact stops being merely data and starts influencing an action. An enterprise may be able to trace a number through its warehouse and still be unable to show which version, interpretation and retrieval of that number an AI agent actually used.

At 10:17 on a Tuesday morning, a commercial agent rejects a proposed customer discount.

The reason recorded in the workflow is straightforward: the account’s projected margin is below the company threshold.

Finance checks the account.

The margin currently showing in its reporting system is above the threshold.

Nothing obvious is broken. The source system is healthy. The warehouse pipeline completed. The semantic model is available. The agent’s tool call succeeded.

The investigation therefore starts with what sounds like a simple question:

Which margin number did the agent actually use?

That question quickly fragments.

Which source records produced it? Which transformation run processed them? Which metric definition was applied? What timestamp did the retrieved value represent? What did the agent receive? What other context surrounded it? And how did that value become one input to an action that altered a live commercial process?

A conventional lineage graph may answer the first half.

The operational incident sits in the second.

What AI data lineage from source to action has to capture

Traditional data lineage is largely concerned with relationships between data assets and the processes that transform them.

That remains essential.

Microsoft Purview, for example, can stitch lineage metadata from supported data-processing systems and show relationships across datasets and downstream analytical assets. Its documentation also acknowledges that automatically generated lineage can sometimes be incomplete, with manual entries and APIs available to fill gaps.

OpenLineage approaches the same problem through execution metadata. Its model distinguishes datasets, jobs and individual runs, while facets can describe the inputs, outputs and other context associated with an execution. Its newer explicit lineage facets can record the actual source-to-target relationships rather than assuming that every input produced every output.

Those mechanisms can establish that:

invoice_lines fed a transformation;

the transformation produced customer_margin;

a downstream dataset consumed that output;

and a particular job run was involved.

For an analytical dashboard, that chain may get close to the answer.

An acting AI system adds more boundaries:

source record → transformation → business definition → retrieved value → agent context → agent execution → tool invocation → business action

The lineage problem is no longer finished when the value reaches the application.

It has to survive the application.

The fact has several identities before the agent sees it

Take the margin value from the opening incident.

At source, it may not exist as a field called customer_margin.

It could be assembled from invoice revenue, rebates, product costs, credit notes and allocation data stored in different systems.

A transformation job turns those records into an analytical result.

Another layer assigns business meaning: perhaps gross margin excludes one category of rebate, applies a specific currency-conversion basis and uses recognised rather than booked revenue.

By the time an agent requests “current projected margin,” the value has accumulated more than provenance.

It has accumulated interpretation.

That distinction matters.

A lineage record saying that column B came from columns X and Y describes derivation.

It does not necessarily prove that the receiving application used the same business definition finance expected.

This is where enterprises can have technically accurate lineage and still struggle to reconstruct an AI decision.

The graph knows where the number travelled.

The incident team needs to know what the number meant at every boundary where its meaning could change.

A dataset edge is not the same as the value an agent consumed

Suppose the warehouse table contained an updated margin of 18.7% at 10:15.

The agent acted at 10:17.

It would be tempting to conclude that 18.7% was the value used.

That conclusion is unsafe without another piece of evidence: the actual retrieval event.

The agent may have queried a cache populated at 09:45.

A retrieval service may have selected a materialised view refreshed every hour.

An API may have returned a rounded or differently filtered figure.

The tool may have been called with the wrong customer identifier.

Or the retrieved object may have contained several margin fields and the agent selected one that happened to sound right.

Data lineage shows possible dependency.

Runtime evidence establishes actual consumption.

That gap becomes particularly important when AI applications introduce retrieval, dynamically selected tools and intermediate application services between the governed data estate and the model.

The evidence chain therefore needs an execution identity that can cross those systems.

A warehouse run ID is useful.

A tool-call ID is useful.

A model trace ID is useful.

An action ID is useful.

Individually, none proves the entire route.

The stronger design is one in which they can be correlated.

The semantic step deserves its own place in the chain

Enterprises often treat semantic metadata as documentation around lineage.

Agents make it operational.

If a metric definition determines how a model interprets a retrieved number, that definition has become part of the execution path.

For the margin example, an investigation should ideally be able to recover more than:

Agent retrieved margin = 14.2.

It should be able to recover something closer to:

Agent retrieved metric projected_customer_margin, definition version 7, calculated for account 4812 as of 09:45, from semantic object 216, using warehouse output from pipeline run 91387.

The precise implementation will vary.

The requirement does not.

A fact used by an agent needs both technical lineage and semantic lineage.

Otherwise, a team may reproduce the value without reproducing the meaning under which the agent acted.

That is a particularly difficult class of failure because neither side of the investigation necessarily appears wrong.

Data engineering can show that the pipeline produced the number correctly.

The application team can show that the agent retrieved the number successfully.

Finance can still show that the wrong metric was used for the decision.

All three statements can be true.

The lineage has to cross into the agent trace

Once the fact enters the agent runtime, conventional pipeline lineage loses visibility unless the application creates another evidence layer.

Observability standards are beginning to make that layer less proprietary.

OpenTelemetry’s Generative AI conventions can represent agent invocations, model calls and tool executions as traces. Its 2026 guidance demonstrates an invoke_agent span with child model and execute_tool spans, allowing the operations inside one agent interaction to be inspected as a connected trace. (OpenTelemetry)

That does not automatically create end-to-end business lineage.

It creates the place where the two worlds can meet.

A tool-execution span can record which enterprise service was called.

The application can preserve the identifier of the retrieved data object or query.

That object can point back to the governed data asset.

The governed asset can point to the transformation run.

The transformation run can point to source datasets.

The result is no longer a single lineage technology.

It is a correlated evidence chain.

This distinction matters architecturally.

Trying to force the warehouse catalogue to describe every model step is likely to produce the wrong abstraction.

Trying to make the agent observability platform reconstruct all upstream data transformations creates the opposite problem.

Each layer should preserve its own evidence and pass enough stable identity across the boundary to reconnect the chain later.

The last edge is the business action

Many lineage designs still stop one step too soon.

They trace the context into the agent and record the tool call.

But the enterprise question during an incident is often:

What changed because of this fact?

In the margin case, the agent did not merely produce an answer.

It rejected a discount.

Another agent might update a vendor record, create a payment instruction, change a replenishment quantity, send a customer communication or open an access entitlement.

The action therefore needs an identity of its own.

A useful reconstruction might connect:

business fact version → retrieval event → agent execution → authorised tool call → target-system transaction

A successful tool call does not by itself identify the durable business effect.

The lineage endpoint should therefore connect the agent event to the target-system transaction or committed state change.

A usable lineage record needs more than a graph

Visual lineage graphs are useful for exploration.

They are less useful if an incident requires people to infer critical execution details from the current state of the graph.

This is not the complete evidence record for the decision. It is the lineage required to follow one material business fact through the systems that transformed, retrieved and acted on it.

The evidence behind that fact should preserve enough history to answer several questions without recreating the environment:

• Which source data contributed to the fact?
• Which transformation and execution run produced the value?
• Which metric or business definition was applied?
• What version of that definition was active?
• What exact value did the application retrieve?
• When was that value valid?
• Which agent execution received it?
• Which tool invocation used or acted on it?
• What transaction or state change resulted?

The requirement for run-level identity is already familiar in data infrastructure. OpenLineage, for example, treats each run as a separately identifiable instance and recommends a unique run ID that can later be tracked.

The harder enterprise work is carrying that discipline across systems that were designed independently.

Gaps should be treated as broken evidence, not inconvenient metadata

There is a practical consequence to this architecture.

A missing lineage edge should not always be classified as a catalogue-quality problem.

If the missing edge prevents the organisation from explaining why an AI system took a consequential action, it is an operational control gap.

Consider four different missing links:

The warehouse cannot identify which transformation produced the value.

The semantic service cannot identify which metric version was applied.

The agent trace cannot identify the retrieved object.

The target system cannot connect the tool call to the resulting transaction.

Each creates a different blind spot.

Together they determine whether the organisation can reconstruct the decision or merely speculate about it.

Microsoft’s own lineage documentation illustrates a smaller version of this reality: supported integrations have specific coverage, and there are cases where lineage is incomplete or needs custom reporting.

AI applications extend that problem beyond the catalogue boundary.

They create new places where provenance can disappear.

The objective is reconstructable source-to-action lineage

The purpose of source-to-action lineage is not to collect every possible piece of metadata.

It is to make an important action explainable at the level at which the action actually occurred.

For the rejected discount, the investigation should eventually be able to say:

The agent used a 14.2% projected margin.

That value came from a particular semantic definition and a particular warehouse output.

The output was generated by a known transformation run from identifiable source records.

The agent retrieved the value from a specific service response.

Its execution trace shows the value entering the decision context.

A particular tool call then rejected discount request 72831.

The discrepancy occurred because the agent’s retrieval layer was still serving the previous semantic version after finance had changed the metric definition.

That is more than data lineage.

It is an account of how one business fact acquired meaning, entered an AI system and became an enterprise action.

As agents gain permission to change business state rather than simply describe it, that is the lineage enterprises will increasingly need.