Metric Lineage vs Causal Lineage

Most modern data platforms have made real progress on lineage. You can click a dashboard tile and trace it back through a semantic model, a transformation, and a raw table, all the way to the source system that emitted the event. This is genuinely useful. When a number looks wrong, lineage tells you whether the pipeline is at fault.

But there is a second question that lineage of this kind never answers. When revenue falls, the issue is rarely a broken join. The issue is that something in the business changed. Conversion dropped. Churn rose. A pricing experiment underperformed. Knowing exactly which table fed the revenue figure does nothing to tell you which of those drivers is responsible.

This is the distinction that matters. There is lineage of data, and there is lineage of cause. They look similar on a diagram. They answer completely different questions.

A Chief Data Officer evaluating a modern stack will see the word lineage on every vendor slide and reasonably assume the problem is solved. It is not. The graph that connects one metric to another, by cause rather than by data flow, is a separate layer. Almost nothing in the standard stack ships it.

Data lineage is a record of provenance. It answers the question: how was this value produced? It follows a value upstream through every transformation until it reaches a source. There are three common flavours, and it helps to name them precisely, because vendors often blur them together.

1. 1

   Dataset lineage

   Table-to-table provenance. This table was built from those tables. Useful for impact analysis when a source schema changes, and for tracing a data quality issue to its origin.

2. 2

   Column lineage

   Field-level provenance. This column is derived from that column through a specific expression. Useful for change management and for auditing how a sensitive field propagates.

3. 3

   Semantic lineage

   Metric-definition provenance. This metric in the semantic layer is computed from these measures and dimensions. Useful for keeping one agreed definition of a number across every tool that reads it.

All three are valuable and all three are about plumbing. They describe how a number is assembled. They are silent on what the number means for the business and on what would make it change. Semantic lineage gets closest, because it lives at the level of metrics, but it still only connects a metric to the data that computes it. It does not connect one metric to another metric that drives it.

Causal lineage is a record of cause. It answers a different question: why did this outcome move? It places a headline metric at the top and decomposes it into the drivers that cause it, then decomposes those drivers in turn, until you reach inputs a team can act on. This is a metric tree, and every link in it is a claim about cause, not a claim about data flow. For a fuller treatment see what is a metric tree.

Consider monthly recurring revenue. Data lineage tells you the figure was built from a subscriptions table joined to a plans table. Causal lineage tells you that revenue is driven by new customers, expansion, and churn, that new customers are driven by qualified leads and conversion rate, and that conversion rate is driven by demo completion and pricing fit. When revenue falls, only the second view lets you walk down the tree and find the input that moved.

The shape looks like a lineage diagram, but read the edges carefully. None of them describe a transformation. Qualified leads is not computed from monthly recurring revenue. It causes it. That single difference is what separates a map of pipelines from a map of the business, and it is the reason this guide exists. The discipline of building this view is covered in metric decomposition.

Set the two next to each other and the gap becomes obvious. They are built from different inputs, they answer different questions, and the people who need them sit in different seats.

The last two rows are the ones a buyer should sit with. Data lineage is now table stakes. You should expect it from any serious warehouse or transformation tool. Causal lineage is the layer almost no one ships, and it is the layer that actually answers the question every leadership meeting opens with.

It is fair to ask why the modern stack does not simply extend lineage into causal lineage. The honest answer is that a warehouse cannot infer cause from data flow, because the information is not there to infer.

This is the behavioural point underneath the technical one. A dashboard shows the outcome. A causal map shows the mechanism. When a team can see the mechanism, and can see which lever they hold, the number stops being a verdict and starts being something they can act on. That shift is the whole game, and it is the reason dashboards vs metric trees is a question worth taking seriously.

If you are assembling or auditing a modern data stack, treat lineage as two requirements, not one. The first is well served by the market. The second is where most stacks quietly leave a hole. These questions separate a tool that traces data from a tool that traces cause.

1. 1

   Can it show me one metric driving another?

   Not which table feeds a metric, but which metric causes another metric to move. If the only graph on offer is dataset, column, or semantic lineage, the causal layer is absent.

2. 2

   Can I trace a top-level change to a specific input?

   When the headline number moves, can you walk down the drivers to the one input that caused it, in a few steps, without writing a bespoke analysis each time?

3. 3

   Does every driver have an accountable owner?

   A causal link with no owner is trivia. Look for RACI on each metric, so Responsible, Accountable, Consulted, and Informed are explicit and the change reaches a named person.

4. 4

   Does it act when a metric moves, or just display it?

   A dashboard waits to be opened. Ask whether the system pushes the change to the accountable owner when a metric breaches expectation, rather than relying on someone noticing.

5. 5

   Does it verify the action worked?

   After an owner acts on a driver, does the system check whether the intended metric actually responded? A verified impact loop closes the gap between deciding and knowing.

Drawing the distinction is the easy part. Making causal lineage a living layer that a company runs on is harder, and it is the part KPI Tree is built for.

KPI Tree sits above the warehouse rather than replacing it. Keep your existing data lineage exactly as it is. On top of it, KPI Tree holds the causal layer the stack does not: a metric tree of drivers where each link is a tested causal relationship, RACI ownership on every metric so each driver has an accountable person, a push to that owner the moment a metric moves against expectation, and a verified impact loop that checks the action changed the number it was meant to change.

The result is a clean division of labour. Your warehouse and transformation tools own data lineage and do it well. KPI Tree owns causal lineage and turns it into something a business runs on. Ownership is what makes the second layer hold together over time, a point developed in why metric trees need ownership.

The two layers are about to matter more, not less, because of how analytics is changing. As natural-language and agentic tools move into the stack, the quality of the answer depends entirely on the quality of the model behind it.

An assistant asked why revenue fell can read data lineage and tell you which tables built the figure. That is not an answer a leader can use. The same assistant, given a causal map with owners, can walk the drivers, find the input that moved, and tell you who is accountable for it. The causal layer is what turns a clever query tool into something that reasons about the business. This is the foundation underneath agentic analytics.