Semantic layer vs business context layer

Most organisations now agree on what their numbers mean. A few years ago that was not true, and the semantic layer was a hard-won prize. Different teams defined revenue differently, active user meant three things in three dashboards, and half of every meeting was an argument about whose number was right. The semantic layer ended that argument by putting one governed definition of each metric in one place, so everyone draws from the same source.

That problem is largely solved. The semantic layer is now commodity and native to the warehouse. The definition of a metric, its aggregation, its dimensions, its joins, its time grain, and who is allowed to query it, all live in the platform the data already sits in. This is genuine progress, and it is also the point at which a new question appears. Once everyone agrees what the number is, the next thing they ask is what to do about it.

That is the whole subject of this guide. The semantic layer is a layer of meaning. The business context layer is a layer of consequence. One tells you what a number is. The other tells you what the number is for. They are not competitors, and the second does not replace the first. It assumes it. A business context layer is only as trustworthy as the definitions underneath it, which is exactly why the two belong in separate layers with a clean boundary between them.

It is worth being exact about the semantic layer, because vagueness here is what lets people imagine it does more than it does. A semantic layer is a governed contract for calculation. For each metric it pins down a small, well-defined set of facts, and it does so once, so that every tool and every person who asks for that metric receives the same answer.

1. 1

   Aggregation

   How the underlying rows roll up into the number: a sum, a count, an average, a distinct count, a ratio. This is the heart of the definition. Two teams reporting different revenue figures are almost always disagreeing about aggregation without knowing it.

2. 2

   Dimensions

   The valid ways the metric can be sliced: by region, by plan, by channel, by cohort. The semantic layer lists which cuts are meaningful and which combinations are not, so a query cannot accidentally produce a nonsensical breakdown.

3. 3

   Joins

   Which tables relate to which, and on what keys, so a metric can be enriched with the attributes it needs. A join relates tables for enrichment. It says these rows describe the same thing, so you may attach this column to that one.

4. 4

   Time grain

   The smallest period the metric is defined at: daily, weekly, monthly. The grain governs how the metric is summed across time and protects against the classic error of averaging an average or double counting a rolling figure.

5. 5

   Access

   Who is permitted to query the metric and at what level of detail. This is role-based access control: a rule about who can read the number, governed centrally rather than re-implemented in every reporting tool.

Hold on to that list, because each item answers a flavour of the same single question: how is this metric calculated. Aggregation, dimensions, joins, and time grain are all about computing the number correctly. Access is about who may receive it. None of them is about why the number moved, whose problem it is, or what should happen next. Those questions are real, they are the ones every meeting is actually about, and the semantic layer is simply not where they live. That is not a flaw. It is a boundary.

A definition is a closed object. Once you have settled aggregation, dimensions, joins, grain, and access, the definition is complete, and it is complete precisely because it does not reach beyond the metric it defines. It says nothing about the metric next to it. This is the right design for a calculation contract and the wrong place to look for a decision.

Consider the question that opens almost every review: this number changed, why. A semantic layer can give you the number, broken down every legitimate way, faster than ever. It cannot tell you that the change was caused by a fall in a different metric two levels down, because the relationship between one metric and another is not part of any single metric definition. The semantic layer knows that two tables join. It does not know that one metric drives another. Those are different kinds of relationship, and conflating them is the central confusion this guide exists to clear up.

These three gaps are not edge cases. They are the substance of running a business with data. A team can have a flawless semantic layer, every metric governed and agreed, and still spend its meetings guessing at causes, leaving problems unowned, and acting without ever checking the result. The definitions were never going to fix that, because answering those three questions is a different job that needs a different layer.

The business context layer is the layer that answers the three questions a definition cannot. It is built from three things, and each maps to one of the gaps above. Together they take a governed metric and give it a cause, an owner, and a fate.

1. 1

   A causal metric tree with confidence on each edge

   A model of how metrics drive each other, where the headline metric sits at the top and decomposes into the drivers that cause it to move. Each edge carries a statistical-significance confidence level, so a driver relationship is a tested claim, not a drawn line. This is what answers why the number moved, and the deeper treatment is metric decomposition.

2. 2

   Per-metric RACI ownership

   A named owner on every metric, expressed as RACI: Responsible, Accountable, Consulted, Informed. There is one Accountable owner per metric, and that role is distinct from who is permitted to query the metric and distinct again from who authored a particular workbook. This is what answers whose job it is to act, treated in full in metric ownership.

3. 3

   Action and a verified impact loop

   When a metric moves, the finding is routed to its accountable owner where they already work, rather than waiting for them to open a tool. After they act, a verified impact loop checks whether the metric moved as the action intended and records the result. This is what answers what is being done about it and whether it worked.

Notice what the business context layer is not. It is not a second place to define metrics. It does not recompute aggregation or hold its own version of the time grain. It reads the governed definitions from the layer below and adds structure on top of them. The semantic layer remains the single source of truth for how each number is calculated. The business context layer is the single source of truth for what each number drives, who owns it, and what happens when it moves. Keeping those responsibilities in separate layers is what keeps both honest.

The cleanest way to see where one layer ends and the other begins is to look at the two ideas people most often blur: relationships and lineage. Each word means one thing in the semantic layer and a different thing in the business context layer, and the difference is exactly the difference between the two layers.

Start with relationships. In the semantic layer, a relationship is a join. A join relates tables for enrichment. It says these two sets of rows describe the same entity, so the attributes of one may be attached to the other. A join is a fact about data structure, and it is symmetric and timeless: orders join to customers whether or not anything is happening.

In the business context layer, a relationship is a driver edge. A driver edge relates metrics causally. It says a movement in this metric is part of the explanation for a movement in that one. A driver edge is directional, it carries a confidence level, and it can weaken or strengthen as the business changes. A join graph and a causal tree can look superficially similar on a screen, and they are not the same object at all. One enriches, the other explains.

Lineage splits the same way. Data lineage traces columns. It follows a field back through the joins and transformations that produced it, so you can see that this revenue column descends from those order rows through that currency conversion. It is indispensable for trust and debugging, and it is entirely a property of the data pipeline. Causal lineage traces what drives what. It follows a metric back up its tree to the drivers that explain its movement, so when retention falls you can walk from the headline number to the specific input that moved first. Data lineage tells you how a number was built. Causal lineage tells you why it changed. The distinction is the whole boundary in one line: lineage of construction belongs to the semantic layer, lineage of cause belongs to the layer above. The deeper treatment is metric lineage vs causal lineage.

It helps to make the business context layer concrete, because abstractly it can sound like a re-description of a data model. It is not. Below is a causal decomposition of a headline metric: the kind of structure the business context layer holds and the semantic layer cannot.

Every node in that tree is a metric, and each one has a governed definition in the semantic layer below. The semantic layer can tell you what Weekly Active Users means and how it is calculated to the row. What it cannot tell you is the thing the tree expresses: that a fall in Product Engagement is part of the explanation for a rise in Gross Churn, which in turn pulls Net Revenue Retention down. That chain is not in any single definition. It is the structure of the layer above.

Read each edge as a tested claim rather than a drawn line. The edge from Gross Churn to Product Engagement carries a confidence level earned by checking, in the data, whether engagement genuinely explains a meaningful and repeatable share of churn once noise and seasonality are accounted for. If it does, the edge stays and Product Engagement becomes a place worth an owner attention. If it does not, the edge is noise dressed up as insight, and the layer should not present it as a lever. This is the difference between statistical driver signals and a hand-drawn diagram that looks authoritative and explains nothing.

Now add the other two parts of the layer. Each node in the tree has an accountable owner through per-metric RACI, so the moment a node moves there is a single named person whose job it is to decide what happens next. When the node moves enough to matter, the finding is routed to that owner, and after they act the verified impact loop checks whether the metric recovered as intended. The tree gives causality, RACI gives ownership, the routing gives action, and the loop gives learning. None of the four is a metric definition. All four sit in the layer above the definitions.

With the boundary drawn, the two layers can be set out directly. The aim of this table is not to diminish the semantic layer, which is essential, but to show precisely which jobs it does and which jobs it leaves to the layer above.

That distinction is worth holding precisely, because it is easy to overclaim and lose the argument. The issue is not that the warehouse is incapable of explanation. It is that an explanation produced ad hoc, on each request, by a query or a narration, is a thing you cannot govern, cannot audit, cannot attach an owner to, and cannot check the next quarter for whether it held. A persistent causal model is the opposite on every count. It is reviewed, it carries confidence, it names who acts, and it learns from whether the action worked. The semantic layer gives an answer. The business context layer gives an answer with a provenance, an owner, and a verdict.

The clearest reason this boundary matters now is what happens when an AI agent is pointed at a business. Give an agent only a semantic layer and you have given it the ability to fetch any number, calculated correctly, on demand. That is real, and it is also the ceiling. An agent with only definitions can return data. It cannot decide, because deciding needs the three things the definitions do not hold.

This is why a semantic layer alone, however good, leaves AI at the level of returning data. The agent can answer what is the number and even narrate a guess at why. It cannot route the finding to an accountable owner it does not know exists, against a causal model it cannot read, and then verify an outcome it has no mechanism to check. The business context layer is precisely the structure that lets an agent go from returning data to driving action, which is the subject of ai agents need business context.

The direction of travel is set by what each layer has already become. The semantic layer has commoditised and moved into the warehouse, which is the natural home for a calculation contract. That is a good outcome. It means the definition of a metric is governed once, close to the data, and every tool above can rely on it. The argument about what a number is, is over.

What that settles is also what it exposes. When everyone agrees on the numbers, the bottleneck moves up a layer, to deciding what to do about them. The next decade of analytics is a competition not over who defines metrics best, but over who builds the most trustworthy layer of context above the definitions: the causal structure, the ownership, the action, and the verification.

The two layers will grow more tightly joined, not merged. The business context layer will keep reading definitions from the warehouse rather than copying them, so governance stays in one place. The causal edges will be tested continuously against the live data the semantic layer governs. Ownership will be read from how the organisation actually works. The push and the impact loop will run with less and less manual tending. Through all of it the boundary holds: the semantic layer owns how a number is calculated, the layer above owns what the number drives, who answers for it, and what is done. This is the architecture behind the wider idea of a business context layer.

KPI Tree is one implementation of the business context layer, built deliberately to sit above the semantic layer rather than replace it. It reads governed metric definitions from the warehouse and from semantic models, detecting how each metric is aggregated automatically, and adds the four things a definition cannot hold: a causal metric tree with a confidence level on each edge, per-metric RACI with one accountable owner, a push to that owner when a metric moves, and a verified impact loop that checks whether the action worked. Your semantic layer tells AI how metrics are calculated. The layer above is how they drive each other, who owns them, and what is being done about it. That is how analysis stops being a number returned and starts being a decision made.