EXPLAINER · SEMANTIC LAYER VS CONTEXT LAYER

Semantic layer or context layer, and do you need both?

Both terms describe a layer of meaning sitting between raw data and whoever is asking questions of it, human or otherwise. They are not the same thing, and the overlap is real enough that teams regularly buy one expecting the other. The distinction gets much clearer if you start from what each was originally built to do, rather than from what either is currently marketed as.

Key takeaways What each holds Side by side Where the line sits Where it shows up FAQ

Key takeaways

A semantic layer exists so that queries agree with each other. It defines metrics, dimensions and joins, and it serves them at query time.
A context layer exists so that meaning is governed. It holds terms, rules, processes, roles and systems, each linked back to the source it came from.
They overlap on metric definitions, and effectively nowhere else.
Neither replaces the other. A semantic layer with no governed meaning encodes whatever the modeller believed on the day, and a context layer does not execute a single query. Metagem is building the semantic layer into the context layer, in early access, so the model inherits the governed definitions instead of repeating them.

What each one actually holds

A semantic layer

A semantic layer sits between your warehouse and the tools that query it, and its job is consistency. It defines a metric once, in one place, so that revenue means the same thing in a dashboard, a notebook and an exported spreadsheet. It holds metrics, dimensions, the joins between tables, and often the access rules that decide who sees what. And it executes: a query arrives, the layer resolves it against the model and returns rows. dbt's Semantic Layer, Cube, Looker's LookML and the Power BI model are all versions of this idea.

It covers the modelled data in your warehouse, it holds the shape of a calculation, and it is optimised for a correct, fast, repeatable answer to a question someone already anticipated.

A context layer

A context layer sits further back and covers more ground. It holds the terms your business uses and what they mean, the rules that constrain them, the processes that produce them, the roles accountable for them, and the systems and fields where they physically live. Every node carries its source, so any claim can be traced to the document or column it came from.

It covers structured and unstructured sources alike, which is the practical difference: most of the rules that govern a metric were never in the warehouse. They are in a policy PDF, a finance manual, a slide someone made for an audit. And it does not execute anything. It has no opinion about query performance because it never runs a query.

Structurally, a context layer is held as a governed context graph: terms, rules, processes, roles and systems as nodes, with typed relationships between them. The graph is the shape; the layer is what the rest of your stack consumes.

A semantic layer answers "what is the number?" A context layer answers "what does this mean, what constrains it, and who says so?"
One is optimised for query time. The other is optimised for being correct and auditable.
The overlap is the metric definition, and it is genuinely the same object viewed from two sides.
A semantic layer is maintained by analytics engineers. A context layer is maintained by domain owners, with agents proposing changes.

Side by side

Swipe the table sideways to see all columns.

Comparison of what a semantic layer and a context layer each hold, cover, and do.
	Semantic layer	Context layer
What it holds	Metrics, dimensions, joins, access rules	Terms, rules, processes, roles, systems and fields
What it is for	Consistent answers at query time	Governed meaning anything can resolve against
Source coverage	Modelled data in the warehouse	Documents and systems, structured and unstructured
Who maintains it	Analytics engineers	Domain owners, with agents proposing
Provenance	Usually the model file and its git history	Every node linked to the document or field it came from
When the business changes	Someone updates the model	Re-extraction proposes the change for review
Executes queries	Yes	No

The row that causes the most confusion is source coverage. A semantic layer can only describe what has been modelled, which means a rule that exists only in a policy document is invisible to it. That is not a shortcoming of semantic layers. It is outside what they were built to cover.

When this is not the right tool

If you run one warehouse and one BI tool, your metrics are already agreed, the rules behind them live in the model rather than in documents, and nobody is disputing the numbers, a semantic layer on its own is proportionate and a context layer is overhead you do not need yet. A context layer starts to pay when the governing rules live in documents your warehouse has never seen, when the same term resolves to different fields depending on which system you ask, or when an agent has to resolve a definition with no analyst in the loop.

HOW METAGEM FITS

Where the line sits

What Metagem supplies

Definitions with owners, the rules and exceptions around them, the processes that produce them, and the mapping down to the fields that carry them. All of it with provenance.

What we are building next

A semantic layer generated from the governed context layer, so metrics, dimensions and joins inherit the definitions and rules rather than being encoded by hand. In early access.

What you keep

Your warehouse and your BI tools, and your existing semantic layer where you have one, consuming governed meaning instead of encoding it separately in each place.

EARLY ACCESS

A semantic layer built from the context layer

We are building the semantic layer into the context layer itself, so metrics, dimensions and joins are generated from governed definitions rather than re-encoded by hand in a separate model. The boundary still holds today: no federation, no virtualisation, no text-to-SQL, and your warehouse remains where the data lives.

See it in Trusted Generative BI

A context layer carries the rules, processes, roles and ownership around a metric, each linked to its source. Metagem supplies that meaning rather than serving the query, so a semantic layer and the BI tools above it consume it rather than being replaced by it.

What's different here

Where it shows up

Metric definitions with their exceptions

The calculation and the carve-outs travel together, so the definition that reaches a tool is the whole rule rather than the formula on its own.

The assumptions behind a calculation

The rules a metric depends on are recorded as rules, not as comments in a model file that only the person who wrote them can find.

Ownership per domain

Each definition has a named accountable role, which is what turns a disagreement about a number into a question with an addressee.

A layer your BI stack consumes

Governed meaning served through one endpoint, so the tools above it stop encoding their own private version of each metric.

Trusted Generative BI

Frequently asked questions

Yes, if you have one and it works. They solve different problems, and nothing here removes the need for a layer that resolves and serves queries. What changes is where the definitions inside it come from: instead of being agreed in a modelling session and encoded by hand, they can be resolved against governed meaning that carries its own provenance. Metagem is also building a semantic layer generated from the context layer, currently in early access, for teams who would rather not maintain a second model by hand.

No. It does not generate queries, execute them, federate across sources or virtualise data, and that stays true as the semantic layer work lands: what is generated from the context layer is the model, not the query engine. The value of the context layer is that it is the authority on meaning, and being the authority on meaning is a different discipline from being fast at returning rows.

It sits behind them. Those tools hold the model and serve the queries; Metagem holds the governed definitions, rules and mappings and exposes them through an endpoint, so the meaning encoded in the model can be traced to an approved definition and an owner. In practice it is a source of truth for the semantic layer rather than a competitor to it.

Then a context layer is a reasonable place to start, because it captures the definitions and rules first and those are what a semantic layer will need anyway. Our own semantic layer, generated from the context layer, is in early access, so that path is worth a conversation. If consistent numbers across dashboards is the immediate pain right now, an established semantic layer is still a sensible purchase, and getting the meaning agreed first tends to make that project shorter.

Bring a metric your teams argue about.

We will show you what the context layer holds behind it: the definition, the rules and exceptions, the owner, and the fields it resolves to.

Talk to our team