What Is a Semantic Layer? Concepts, Benefits, and Approaches

A semantic layer is the place where your business definitions live: what a customer is, how revenue is calculated, which tables join to which and on what key. It sits between the warehouse and everything that queries it, so a dashboard, a notebook, a spreadsheet export and an AI agent all resolve "monthly churn" to the same SQL. Without one, each tool re-derives the logic and the numbers drift apart.

The idea is decades old — it used to be called a universe or a business layer — but it matters more now for a specific reason: language models are extremely good at writing SQL and extremely bad at guessing which of your seven revenue columns is the real one. The semantic layer is what stops a capable agent from being confidently wrong.

What a Semantic Layer Actually Contains

• Business terms. Mappings from human vocabulary to physical fields, so nobody needs to know that cust_id is the account key and cust_id_v2 is deprecated.

• Relationships and joins. The permitted paths between entities, including the ones that produce fan-out if you get them wrong. This is where most incorrect AI answers originate.

• Metrics. A single expression per metric, with its filters and grain: active customer, qualified lead, gross margin, net revenue retention.

• Filters and caveats. The unglamorous knowledge — exclude internal test accounts, exclude the 2023 migration cohort, revenue is recognised in the billing table not the orders table — that separates a correct answer from a plausible one.

• Access rules. Which roles may see which rows and columns, ideally expressed so the warehouse can enforce them.

• Trusted queries. Known-good SQL for recurring questions, which doubles as training material for both new analysts and agents.

Four Approaches, Compared

There are four broadly different places to put this layer, and the choice has long consequences because the layer accumulates value slowly and is painful to move.

The fourth approach is the newest and is worth explaining because it changes who maintains the layer. Instead of a modelling language only two people know, context is stored as files an analyst can read: a Markdown file describing what churn means, a SQL file with the trusted query, a Python file for a shared transformation. Because it lives in the same repository as your dbt project, a change to a model and a change to its definition can arrive in the same pull request — which is the only reliable cure for the sync treadmill where dbt evolves faster than the semantic layer that describes it.

This is Querio's approach. The agent proposes updates as it learns your schema — "save this as the reusable churn definition?" — and only logged-in humans approve and commit them. Because the files are plain and yours, they keep working with Claude Code or any other agent, with or without Querio. The strategic argument is simple: context is the expensive asset, and an asset your vendor stores for you is an asset you have partially rented. See what a governed context layer is and building a semantic layer that understands your business.

The Open Semantic Interchange

One reason the portability question is live: in 2025, a group of data and analytics vendors including Snowflake, dbt Labs and Omni announced the Open Semantic Interchange (OSI), an initiative to define a vendor-neutral specification for semantic models — metrics, dimensions and their relationships — so definitions can move between tools instead of being re-authored in each one.

Described neutrally: it is an early industry effort rather than a finished standard, and its practical value will depend on how many tools implement it and how faithfully. But its existence tells you something useful about the direction of travel. Vendors are responding to a real customer complaint — that semantic definitions are trapped — and buyers are increasingly treating portability as a purchasing criterion rather than a nice-to-have. If you are choosing a semantic approach now, ask each vendor how definitions can be exported, in what format, and whether anything is lost in the round trip.

Why AI Makes This Urgent

A language model asked "what was net revenue retention last quarter?" against a raw schema has to guess: which table, which join, which date column, whether to exclude test accounts, whether refunds are already netted. Each guess is individually reasonable and collectively wrong. Give the same model a definition file that answers those questions and the task reduces to composing known-good pieces — a much easier problem, and one where errors are visible because you can read the generated SQL.

There is a second, less obvious benefit: cost and consistency across sessions. Without persistent context, every new agent session rediscovers your schema, spending tokens and time and getting a fresh chance to get it wrong. With context, month three is better than week one, because approved definitions accumulate. That is the difference between an agent that is impressive in a demo and one that is trusted in a quarterly close.

The third benefit is auditability. When definitions are files in Git, "why did this number change in April?" has an answer: a commit, an author and a reviewer. Related reading: why semantic context is key to better AI analytics and how governed context prevents wrong answers.

Semantic Layer vs. Metrics Layer vs. Data Model

The vocabulary is muddled, so briefly: a data model (usually dbt, usually a star schema) shapes physical tables. A metrics layer defines calculations on top of that shape. A semantic layer is the broader thing — metrics plus vocabulary, relationships, caveats and access rules — that lets a consumer ask a question without knowing the physical layout. In practice most teams need dbt for the first and something for the other two; the argument is only ever about where that something lives. See metrics layer versus semantic layer and semantic layers versus traditional data models.

How to Start Without a Six-Month Project

1. Pick five metrics, not fifty. The ones on the leadership dashboard. If a metric has never caused an argument, it does not need governing yet.

2. Write each definition in prose first, then in SQL. If two people write different prose, you have found the real work — and it is a business conversation, not a technical one.

3. Commit them where your dbt project lives. One directory, one file per metric, reviewed like any other code change.

4. Add the caveats. Test-account filters, cohort exclusions, timezone conventions. These are what make an answer right rather than merely computable.

5. Wire one consumer — the tool or agent people actually use — and confirm its answers match the hand-calculated ground truth.

6. Grow by exception. Every time a question needs logic that is not yet defined, that is the next definition. Let the backlog write itself.

7. Review quarterly. Definitions rot when the business changes. A short recurring review beats an annual audit nobody schedules.

A useful rule: if a definition cannot be explained to a new analyst in two sentences, it is probably two definitions.

FAQ

Do I need a semantic layer if I already have dbt?

dbt shapes tables; it does not by itself tell a tool or an agent which of those tables to use for "revenue this quarter", or which filters apply. Many teams get the rest of the way with a small set of definition files committed next to their dbt models, rather than adopting a separate service.

Does a semantic layer slow queries down?

Not inherently. Layers that compile to SQL and push execution to the warehouse add negligible overhead; the performance question is whether the generated SQL matches your table partitioning and clustering. Because the SQL is inspectable, you can profile it like any other query.

Who should own the semantic layer?

The data team owns the mechanics; the business owns the meaning. The failure mode is a data team inventing definitions in isolation, then discovering at quarter-end that finance disagrees. Put the definition in a pull request and require a business reviewer on the ones that matter.

What happens to my definitions if I change tools?

That depends entirely on the approach you chose. Definitions inside a BI platform's proprietary modelling language must be rewritten. Definitions in plain files in your own repository move with you and remain readable by any agent. This is the single most consequential difference between the four approaches above.

Is a semantic layer worth it for a small team?

Yes, at a small scale. Five metric files and a caveats document is a semantic layer, and it will save a five-person company more arguments per head than it saves a five-hundred-person one. The mistake is treating it as an enterprise-only project with a formal tool selection attached.