Definitions are not decisions
Semantic views vs metric trees
A semantic view or metric view models relationships as joins and metrics as aggregations within a table. A metric tree models an outcome as the drivers that cause it to move, with confidence on each edge and an owner on each node. This guide draws the line precisely.
11 min read
What the two layers actually model
Definition
A semantic view (also called a metric view) is a governed definition layer in the warehouse. It declares how tables relate through joins and how metrics are calculated through aggregations, so every tool that reads it computes the same number the same way. A metric tree is a hierarchical model that sits above that layer. It places a headline outcome at the top and decomposes it into the drivers, sub-drivers, and inputs that cause it to move, where each edge is a tested causal relationship and each node carries an owner.
Most teams now agree on the value of a single source of truth for definitions. A semantic view is exactly that. It says revenue means this aggregation over this table, joined to these dimensions, filtered this way. Once that is written down once, a dashboard, a notebook, and an AI agent all return the same figure. This is real progress, and it is foundational.
But a definition is not a decision. Knowing precisely how revenue is calculated does not tell you why it fell last week, which input moved first, or whose job it is to respond. The semantic view answers what the number is. It was never designed to answer why the number changed or what to do about it. That gap is the reason metric trees exist.
The cleanest way to see the difference is to look at the unit of relationship in each model. In a semantic view, the unit is a join: it relates two tables so you can enrich one with the other. In a metric tree, the unit is a driver edge: it relates two metrics causally, so a movement in one is understood to move the other. A join is a structural fact about your data. A driver edge is a behavioural fact about your business.
The semantic view
Lives in the warehouse. Models joins and aggregations. Guarantees that every consumer calculates a metric the same way. The trustworthy definition of what.
The metric tree
Lives above the warehouse. Models causal driver edges and owners. Explains why an outcome moved and routes the response. The operating model for why and what next.
A join relates tables, a driver edge relates metrics
It is worth being precise about the two kinds of relationship, because they look similar on a diagram and mean very different things.
A join in a semantic view connects an orders table to a customers table so that you can group revenue by region or by plan. The relationship exists because the rows share a key. It is true regardless of what the business does. Nothing about a join tells you that one metric causes another to move.
A driver edge in a metric tree connects revenue to traffic, conversion rate, and average order value. The relationship exists because, in this business, those inputs combine to produce that outcome. When conversion rate drops, revenue drops, and the edge is what lets you trace the one back to the other. The edge is a claim about cause, and a good metric tree treats it as a claim to be tested rather than assumed.
The honest distinction
A join relates tables for enrichment. A driver edge relates metrics causally. You can build a perfect semantic view full of correct joins and still have no model of which metric drives which. The two are complementary layers, not competing ones. This is the heart of metric decomposition.
This is also why a semantic view cannot, on its own, tell you why a number moved. It can be queried ad hoc to slice the number a dozen ways, and an AI assistant can narrate a plausible story over those slices. But neither traverses a governed, persistent model of cause. The slicing is transient and the narration is generated fresh each time, which means there is nothing durable to govern, no confidence attached to a claim, and no owner waiting on the other end.
Semantic or metric view vs metric tree, side by side
Set the two layers against each other across the dimensions that decide real outcomes. The point is not that one wins. The point is that they do different jobs, and most teams have only built the first.
| Dimension | Semantic or metric view | Metric tree |
|---|---|---|
| Unit of relationship | A join between tables, keyed on a shared column | A driver edge between metrics, expressing cause |
| What it models | How metrics are calculated and how tables relate | Why an outcome moves and which inputs drive it |
| Ownership | None at the metric level, it is a definition not a responsibility | A RACI holder on every node, so each driver has an accountable owner |
| Action | Returns a correct number when queried | Pushes the moved metric to the owner who can act on it |
| Verification | Confirms the calculation is consistent across tools | Closes a verified-impact loop confirming the response actually moved the metric |
| Who it serves | Analysts and engineers who need one trusted definition | Operators and owners who need to know why and what next |
Read the table top to bottom and a pattern appears. The semantic view is built around correctness and consistency, which are properties of a definition. The metric tree is built around causation, ownership, and proof, which are properties of a decision. You want both, layered, with the definition feeding the tree.
What a driver tree looks like
Take a single headline metric and decompose it. Revenue is the outcome at the top. It is driven by traffic, conversion rate, and average order value. Each of those decomposes again into the inputs a specific team controls. Every line is a driver edge, and in a governed tree every edge carries a significance test and a confidence level, while every node carries an owner.
A semantic view can supply every number in this picture, correctly and consistently. What it cannot supply is the shape itself. The view does not know that conversion rate sits under revenue as a cause, nor that checkout completion rate is the input a particular team owns. That structure is the contribution of the tree, and it is what turns a pile of correct numbers into a map you can act on. The same idea, applied to financial and operational outcomes, is the value driver tree.
Why the edge needs confidence
Drawing an edge from conversion rate to revenue is a hypothesis until it is tested. A governed tree attaches a significance test and a confidence level to each edge, so an owner can tell a strong driver from a weak one before they spend a week chasing it. Definitions never carry confidence, because a definition is not a claim about the world. A driver edge is.
Why ownership belongs on the tree, not the view
Ask who owns revenue and you will get a shrug or a committee. Ask who owns checkout completion rate and you can usually name a person. That is the practical reason ownership lives on the leaves and branches of a tree, not on a top-line definition. The further down the tree you go, the more actionable the metric and the clearer the owner.
A semantic view has no natural place to record this. It defines the metric, not the responsibility. So the moment a number moves, the trail goes cold: the definition is intact, but nobody is named, and the meeting fills with the same question every time. Why?
- 1
Assign RACI to each node
Every metric in the tree carries Responsible, Accountable, Consulted, and Informed roles. The accountable owner is the single name on the hook when that metric drifts.
- 2
Route the movement to the owner
When a metric moves beyond its expected range, the change is pushed to the accountable owner directly, rather than waiting to be noticed on a dashboard nobody opened.
- 3
Give the owner the causal context
The owner does not just see that their metric moved. They see where it sits in the tree, which parent it feeds, and which child inputs may have caused it, with confidence on each edge.
- 4
Verify the response
After the owner acts, the verified-impact loop checks whether the metric returned to expectation, so the organisation learns which interventions actually work.
None of these four steps is something a semantic view was built to do, and that is not a criticism of the view. It is a definition layer doing its job. The work of assignment, routing, context, and proof is a layer above. For the full treatment of how this changes behaviour, see why metric trees need ownership.
How the layers fit together
The right mental model is a stack, not a contest. The semantic view is the foundation: it defines how each metric is calculated, warehouse-native, governed once. The metric tree sits on top: it reads those definitions and adds the causal structure, the ownership, the routing, and the verification.
Definition layer
A warehouse-native semantic or metrics layer. It owns the calculation. KPI Tree reads these models and detects how each metric is aggregated automatically.
Causal layer
The metric tree. Driver edges with significance tests and confidence levels turn a flat list of definitions into a map of cause.
Accountability layer
RACI ownership on every node, with movements pushed to the accountable owner so the right person responds without being chased.
Verification layer
A verified-impact loop that confirms the response moved the metric, so the organisation compounds what it learns.
“You do not replace the definition layer. You build the decision layer on top of it.”
Because the tree reads the definition layer rather than redefining it, the number an owner acts on is the same number the analyst trusts. There is no second source of truth and no reconciliation. The deeper case for treating the layer above the warehouse as its own discipline is in semantic layer vs business context layer.
Which one does your question need?
A simple test settles most cases. Look at the question in front of you and ask whether it is a question of definition or a question of decision.
| Your question | The layer that answers it |
|---|---|
| What is our revenue this quarter, calculated consistently | Semantic or metric view |
| Why did revenue fall last week, and which input moved first | Metric tree |
| How is conversion rate defined and joined to channel | Semantic or metric view |
| Who owns checkout completion rate and have they been told it slipped | Metric tree |
| Did the fix we shipped actually move the metric back | Metric tree |
| Does every tool return the same number for active users | Semantic or metric view |
If your questions cluster in the top group, invest in a clean semantic view first, because nothing above it works without trustworthy definitions. If your questions cluster in the bottom group, you have outgrown the view alone, and the gap you feel in every meeting is the absence of a causal, owned, verified layer above it.
Where this is heading
The definition layer is becoming a commodity, and that is healthy. Every serious warehouse now ships a way to govern how metrics are calculated, and AI assistants can read those definitions to answer what a number is. The scarce thing is no longer the definition. It is the model of cause and accountability that sits above it.
This matters more, not less, as AI agents take on analysis. An agent reading only a semantic view can compute any number and narrate a plausible story about why it moved, but it has no governed causal model to traverse, no confidence to weigh, and no owner to hand the work to. An agent reading a metric tree can trace the moved metric to its likely driver, weigh the confidence on that edge, name the accountable owner, and check afterwards whether the response worked. The difference is the difference between a fluent guess and a governed answer.
The takeaway
A semantic view tells you what your numbers are. A metric tree tells you why they moved, who should act, and whether the action worked. Build the first as your foundation. Build the second to turn definitions into decisions.
Continue reading
Semantic layer vs business context layer
A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.
Metric decomposition
Break any business metric into the components that drive it
Value driver tree
Map the causal chain from financial outcomes to the operational levers that produce them
Build the layer your semantic view was never meant to be
KPI Tree reads your semantic models and detects how each metric is aggregated, then adds the causal tree, the ownership, and the verified-impact loop above it. See why your numbers move and who should act.
