Business context layer

A business context layer is the part of a modern data stack that captures how a business actually works, so that a metric is never just a number. It records the company model of itself: the relationships between metrics, the named owner of each one, the agreed definition of each metric, and the history of decisions taken against those metrics and whether they moved the number as intended. Where a warehouse stores the data and a semantic layer defines how each metric is calculated, the business context layer sits above both and adds the meaning a definition cannot hold, namely why a metric matters, what drives it, who answers for it, and what has already been tried.

The layer exists because agreeing what a number is does not tell you what to do about it. A business might have a governed definition of its conversion rate and still spend every review guessing at why the figure fell, leaving the problem unowned, and acting without ever checking whether the action worked. Those three questions, what drives a metric, who owns it, and what is being done about it, are the substance of running a business with data, and none of them lives inside a metric definition. The business context layer is where they live.

A business context layer is built from a small number of things, and each one answers a question a raw metric leaves open. Together they take a governed number and give it a cause, an owner, and a fate.

1. 1

   A model of the business as a causal metric tree

   A structure that maps how metrics drive each other, with a headline metric at the top decomposing into the drivers that cause it to move. This is a metric tree, and each relationship is tested statistically rather than drawn by hand, so a driver edge is a claim the data supports rather than an assumption on a diagram.

2. 2

   Agreed definitions for every metric

   The context layer reads the governed definition of each metric, its aggregation, dimensions, and time grain, from the semantic layer beneath it rather than redefining anything. That keeps a single source of truth for how each number is calculated and lets the layer above build on it without fracturing it.

3. 3

   Named owners with clear accountability

   One accountable owner on every metric, expressed as RACI: Responsible, Accountable, Consulted, and Informed. Permission to query a number is not the same as responsibility to act on it, and the second is what turns a falling metric into a decision that someone actually makes.

4. 4

   A history of decisions and their outcomes

   A record of what was done when a metric moved and whether it moved the number as intended. Actions are tracked against the metric they were meant to change, so the layer learns which levers work over time instead of repeating the same guesses.

A semantic layer defines what a metric is and how it is calculated: its aggregation, its dimensions, its joins, its time grain, and who is allowed to query it. That is a governed contract for calculation, and it answers a single question well, which is how this metric is computed. A business context layer sits one level above it and answers the questions a definition cannot: how metrics drive each other, who is accountable when one moves, and what is being done about it. The semantic layer settles what a number means. The business context layer settles what the number is for. The two are not competitors, and the second does not replace the first, it assumes it. For a fuller treatment of the boundary, see semantic layer vs business context layer.

Point an AI agent at a warehouse and a semantic layer and it can fetch any metric, calculated correctly, on demand. That is genuinely useful, and it is also the ceiling. An agent with only definitions can return data, but it cannot decide, because deciding needs the things a definition does not hold: the causal structure that says which lever to consider, the ownership that says whose decision a finding is, and the record of what has already been tried and whether it worked. A business context layer gives an agent that structure, so it can move from returning a number to proposing an action and checking the result.

It helps to make the layer concrete, because in the abstract 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 a business context layer holds and a semantic layer cannot.

• Net Revenue Retention
  • Expansion Revenue
    • Seat Expansion Rate
    • Upgrade Rate
  • Gross Churn
    • Product Engagement
      • Weekly Active Users
      • Feature Adoption
    • Time to Resolution

Every node in that tree is a metric with a governed definition in the semantic layer below. What the semantic layer cannot express is the thing the tree captures, 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. Each edge carries a confidence level earned by testing, in the data, whether the driver genuinely explains a meaningful and repeatable share of the movement once noise and seasonality are accounted for. Add a named owner to each node, a route to that owner when the node moves, and a check on whether the fix worked, and the tree stops being a diagram and becomes the structure a decision runs through.

KPI Tree is one implementation of a business context layer, built to sit above the semantic layer rather than replace it. Its context layer is named Canopy: it reads governed metric definitions from the warehouse, then adds 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. The semantic layer tells an agent how metrics are calculated. The layer above tells it how they drive each other, who owns them, and what is being done about them, which is how analysis stops being a number returned and starts being a decision made.