Your semantic layer is your context layer

Every company that has tried to put an assistant in front of its data has run the same experiment, whether or not they meant to.

Point a capable model at the warehouse. Ask it a business question. Watch it write SQL that is syntactically perfect, semantically confident and quietly wrong — because it had to guess which of your four customer tables is current, whether cancelled orders count, and what your business means by "active".

The reflex is to blame the model, then try a bigger one. The bigger one guesses more fluently.

The model is not missing intelligence, it is missing context#

A normalised warehouse is a compression of your business logic. The logic itself — which rows count, which dates apply, what an exclusion means — lives in three places: the heads of four people, a handful of long-running reports, and a spreadsheet somebody maintains out of duty.

None of those are readable by a model. So it reconstructs the logic from the only artefact it can see: your table and column names. Given fct_loans, dim_customer_v3 and a column called status, it produces a plausible reconstruction of a business it has never seen.

The fix is not a better reconstruction. It is to stop asking for one.

What a context layer actually is#

Three properties, and they are the whole job.

Defined once. Every metric exists in exactly one place, with its exclusions inside the definition rather than remembered by whoever wrote the last report. In practice this is dbt: models for the entities, metrics for the measures, tests for the assumptions.

Described for a machine. Descriptions used to be documentation nobody read. Now they are the prompt. A column comment that says "loan status; 1 = applied, 3 = disbursed, 7 = written off; only 3 and 4 count as active" does more for answer quality than any amount of prompt tuning, because it removes a guess rather than nudging one.

Served as tools, not tables. This is the part most teams skip. An assistant that can select from a small set of well-described metrics — approval_rate, sliced by market and month — is doing lookup. An assistant that can write arbitrary SQL is doing archaeology. Same model, radically different reliability, because you narrowed what it can get wrong.

The dbt Semantic Layer does this natively. Exposing it through an MCP server turns your metrics into callable tools any assistant can reach without ever seeing a schema.

The unglamorous checklist#

If you want a concrete version of what we build in the first weeks of a Context Pod, it is roughly this:

1. Pick the twenty metrics the business actually argues about. Not all of them. The ones that appear in board packs and Slack disagreements.
2. Write the definition down, including exclusions, and get it agreed by the people who will dispute it later. This is a political exercise disguised as a technical one and it takes longer than the code.
3. Implement each one once, in dbt, with tests that fail if the assumption stops holding.
4. Describe everything — model, column, metric — in plain sentences that state what is excluded and why.
5. Add contracts on the sources underneath. An AI system fails silently on schema drift where a dashboard fails loudly.
6. Expose the metrics as tools. Semantic Layer, MCP, or an internal API. What matters is that the assistant selects rather than composes.
7. Carry row-level security through. If a regional manager cannot see another region in Power BI, they must not be able to ask an assistant instead.
8. Score it. Fifty real questions with known answers, run on every change.

Nothing on that list is exotic. Most of it is work an analytics engineer already knows how to do. What changed is that it went from a nice-to-have to the thing that determines whether your AI project ships.

Why this order matters commercially#

The tempting sequence is model first, context later — because the model demos and the context does not.

The problem is that the demo sets the expectation and the context sets the reality, and the gap between them is where projects die. We have been called into several rescues that were all the same shape: an assistant launched to enthusiastic internal users, accuracy quietly around seventy percent, trust gone within a quarter, and a much harder conversation to have the second time.

Seventy percent is a strange number. It is high enough to look like it works and low enough to be dangerous, because nobody can tell which thirty percent to check.

A tool that is right seven times out of ten teaches people to stop checking. That is worse than a tool that is right five times out of ten, which teaches them to check everything.

Building the context layer first inverts this. Accuracy starts high because the assistant can only reach things that are already correct. The scope is narrow, which looks less impressive in a demo and holds up in production.

What this is not#

It is not a data catalogue. A catalogue tells a human where to look. A context layer tells a machine what is true.

It is not a warehouse migration. You can do this on what you already have. If your pipelines are genuinely broken, that is a different problem and you should fix it first — but "our dbt project is messy" is not a reason to wait.

And it is not a one-off. Definitions drift because businesses change. The tests and the golden set are what keep the layer honest after the consultants leave, which is why we treat both as deliverables rather than as extras.

The short version#

If you are choosing between spending the next quarter on model selection or on metric definitions, spend it on metric definitions. Models improve on their own, roughly every six months, at no cost to you. Your business logic does not write itself down.

Whatever model you end up using will be better than the one you would have picked. But it will still not know what your company means by revenue.