What Is a Semantic Layer? A Practical Definition for Data Teams

Ask five people in your company what "monthly active user" means and you'll get three definitions and two shrugs. The data is fine — the meaning is scattered. A semantic layer is where that meaning lives.

The definition

A semantic layer is a shared, executable model of what your data means, sitting between raw sources and every tool or person that queries them.

Two words in that definition do the heavy lifting:

• Shared — one model serves BI dashboards, AI chat, scheduled reports, alerts and APIs. Definitions are not copy-pasted into each tool.
• Executable — it isn't documentation. When a question arrives, the layer actively resolves terms, chooses joins, applies definitions and enforces policy to produce correct SQL.

What's inside a semantic layer

Component	What it captures	Example
Entities	What business objects exist	"A patient is a row in residents where type != 'test'"
Relationships	Valid joins between tables	"invoices.customer_id → customers.id"
Metrics	Precise calculations	"NRR = starting ARR + expansion − contraction − churn, ÷ starting ARR"
Glossary	Business language → schema	"'Enterprise' means plan_tier IN ('ent','ent_plus')"
Policy	Access and masking rules	"Analysts see ssn as [restricted]"

Most teams have all five of these somewhere — in dbt YAML, a Confluence page, a senior analyst's head. The semantic layer's job is to make them one governed, machine-readable source of truth. We go much deeper on architecture in the complete semantic layer guide.

A concrete example

Someone in finance asks: "What was enterprise churn in Q2?"

Without a semantic layer, an LLM (or a new analyst) has to guess:

• Which table holds subscriptions? subs, subscriptions, or subs_v2?
• Does "enterprise" mean a plan tier, a seat count, or a sales segment?
• Is churn counted by logo, by seat, or by revenue? Do trials count?

Every guess is a chance to be confidently wrong — which is exactly why LLMs hallucinate on analytics.

With a semantic layer, none of that is guesswork. "Enterprise" resolves to plan_tier IN ('ent','ent_plus'), churn has one signed-off definition, the join path is known, and the generated SQL ships with the answer so anyone can verify it.

What a semantic layer is not

• Not a data catalog. Catalogs help humans find and document datasets. Semantic layers answer queries. (Full comparison here.)
• Not just a metrics store. Metrics are one component; entities, glossary and policy matter just as much — especially for AI consumers.
• Not another copy of your data. A good semantic layer generates queries against your existing warehouse; it doesn't extract and re-store your data.

Why now: the AI forcing function

The semantic layer idea is old — Business Objects shipped "universes" in the 1990s. What changed is that query generation became automated. When humans wrote all the SQL, tribal knowledge could paper over missing semantics. When an LLM writes the SQL, there is no tribal knowledge — only what the model can see. Give it raw schema and you get plausible fabrications; give it a semantic layer and you get governed text-to-SQL.

That's the design principle behind Sema: connect a source, let discovery draft the model, review the glossary, and every plain-English question from then on is answered with governed, explainable SQL.

Where to start

Don't boil the ocean. Pick the one source that generates the most questions, connect it, and encode the five metrics your company argues about most. A semantic layer earns trust definition by definition — and once the AI answers match the CFO's spreadsheet, adoption takes care of itself.