Beyond the semantic layer: what your warehouse cannot decide

For a long time the semantic layer was the hard part. Teams spent months agreeing on what a metric meant, where it lived, and how it should be aggregated, so that the same number did not arrive three different ways in three different meetings. That work was valuable, and it was scarce.

It is no longer scarce. Governed metric definitions now ship inside the warehouse itself as a native, supported feature. The transformation tools that sit on top of the warehouse have offered the same thing for years. Defining a metric once and reading it consistently everywhere has moved from a differentiated capability to an expected one. If you have a modern warehouse or a metrics layer, you already have this, or you are one configuration away from it.

That is genuinely good news. It removes a real source of friction and a real source of error. But it also resets where the value sits. When governed business context becomes a commodity inside the warehouse, owning the definition stops being a moat. Everyone has it.

So the interesting question is no longer how do we agree on the number. It is what can we do that the layer underneath structurally cannot. A semantic layer is a dictionary. A dictionary tells you what a word means. It does not tell you why the sentence is true, who wrote it, or what to do next. To see the gap clearly it helps to separate metric lineage vs causal lineage, and to be precise about what a semantic layer vs business context layer each holds.

The reason a semantic layer cannot answer the question every leader actually has is not a missing feature. It is the shape of the thing. A semantic layer is a definition store. Its job is to map a name to a calculation. Asking it why a number moved is like asking a dictionary why a sentence is true. The category of answer is not in there.

When a metric drops and someone needs to know why, a definition store can only do one of two things. It can run an ad-hoc query, slicing the metric by dimension after dimension until a human spots something that looks like a cause. Or, increasingly, it can hand the same slices to a language model and have it narrate a plausible explanation in prose. Both can be useful. Neither is the same as reading a governed, persistent model of what actually drives the metric, with a confidence level on each link and a named owner attached.

The four rows that the semantic layer leaves blank are not edge cases. They are the difference between a number and a decision. The rest of this guide takes them one at a time.

A semantic layer defines metrics. The four capabilities below are about deciding what to do when a metric moves. None of them live in a definition store, because none of them are about how data is structured. They are about how the business works, who runs it, and whether the last thing you tried made any difference.

Read together, these four form a loop, not a list. The tree finds the cause, ownership routes it to a person, the push reaches that person with the cause named, and the verified-impact loop closes the circle by checking the result and feeding it back. The semantic layer is the foundation the loop stands on. It is not the loop.

A semantic layer can tell you that Revenue is down. It cannot tell you that Revenue is down because expansion revenue fell, which fell because seat upgrades fell, which fell because activation in a single onboarding step dropped last week. That chain is causal structure, and a definition store does not hold it.

The layer above does. It places the headline metric at the top and decomposes it into the drivers, sub-drivers, and inputs that cause it to move. Each relationship is a value driver tree edge, and crucially each edge is tested for statistical significance and carries a confidence level. That is what separates a real driver from a number that merely happened to wobble at the same time. The platform reads the metric definitions and calculation logic straight from your existing semantic models, detecting the aggregation automatically, so the tree is built on the governed numbers you already trust rather than a second, divergent copy.

The difference between this and ad-hoc slicing is permanence and confidence. Ad-hoc analysis rebuilds the reasoning from scratch every time and leaves nothing behind. A governed causal tree is persistent, so the same structure is there next month, the significance of each link is known rather than guessed, and the explanation does not depend on which analyst happened to run the query. For the deeper treatment of how these edges are discovered, see statistical driver signals.

A cause with no owner is trivia. The second capability is metric ownership made structural: every metric and every driver in the tree carries an explicit RACI assignment. Responsible is the person doing the work. Accountable is the single name on the hook for the outcome. Consulted and Informed capture who needs a say and who needs to know. A semantic layer has no column for any of this, because calculation logic and accountability are different kinds of thing. For why this is not optional, see why metric trees need ownership.

1. 1

   A metric moves

   The headline number crosses a threshold or breaks from its expected trend. The system notices, rather than waiting for someone to open a dashboard.

2. 2

   The tree names the cause

   The causal model is traversed to find the specific driver edge responsible, with its confidence level, so the alert carries a reason and not just a red figure.

3. 3

   RACI resolves the person

   Ownership on that driver identifies the accountable owner. The message is routed to the one name on the hook, not broadcast to a channel that everyone mutes.

4. 4

   The push lands with context

   The owner is reached where they already work, told which metric moved, by how much, and which driver caused it. They open already knowing what happened and why.

This is the third capability, and it depends entirely on the first two. A semantic layer can be polled, but it has nobody to tell and nothing to say beyond the number. Because the layer above holds both the causal edge and the owner, the push is specific. It reaches the accountable person the moment the metric moves and it names the driver that caused the move. The signal arrives pre-explained, which is the difference between an alert that gets acted on and one that gets dismissed.

The last capability is the one almost nothing in the stack does, and it is the one that compounds. After the accountable owner takes an action, something has to check whether it worked. Not whether a ticket was closed. Whether the metric actually responded. That is verified impact: the loop watches the relevant metric after the intervention and grades the result against what was expected.

A semantic layer cannot do this for a simple reason. It has no memory of the action. It was never told an intervention happened, it holds no link between that intervention and the metric, and it has no notion of before and after to compare. It can tell you the number today. It cannot tell you that the number is where it is because of what someone did three weeks ago.

Closing the loop changes the character of the whole system. Without verification, every intervention is a guess that nobody grades, and the organisation makes the same guesses for years. With verification, the system accumulates evidence about which actions move which drivers, and that evidence flows back into the causal tree. The tree gets sharper, the pushes get better targeted, and the next decision is made with more signal than the last. A definition store, by design, learns nothing.

Step back and the strategic picture is clear. Governed business context, the thing the semantic layer provides, is commoditising inside the warehouse. It is becoming a feature you switch on, not a system you build. That is the right outcome, and it should be celebrated rather than defended.

But it relocates the value. When everyone has the same governed definitions, owning the definitions is not an advantage. The advantage moves up a layer, to the things the definition store cannot hold: the causal model of what drives each metric, the ownership that turns a number into someone responsibility, the push that reaches that person the instant it matters, and the verified loop that proves whether the response worked.

This is what KPI Tree is for. It reads your existing semantic models, detecting aggregation automatically, and adds the four capabilities the layer underneath structurally cannot: a causal driver tree with confidence, per-metric RACI ownership, a push that names the driver to the accountable owner, and a verified-impact loop. It does not replace your warehouse or your metrics layer. It stands on them and supplies the part they were never built to do. The category for that layer is decision intelligence, and its building blocks are the four primitives of decision intelligence.

Putting a governed decision layer above the semantic layer does more than answer why a number moved. It changes who, and what, can ask. The same persistent causal model that routes a push to a human owner is exactly the context an automated agent needs to reason about a business rather than narrate a chart. An agent reading a governed causal tree with owners attached can find the cause, identify the responsible person, and check whether a prior action worked, because that structure is now stored rather than improvised.

This is why the conversation is moving past consistent definitions and toward governed context that something, or someone, can act on. For where this leads, agentic analytics and the argument that ai agents need business context both pick up exactly where the semantic layer stops. The definition is free now. What you build on top of it is the whole game.