A semantic layer holds the definitions of metrics, entities, and access rules that everything querying your data shares. We build these layers at Xavor Corporation in Irvine, California through our BI and data analytics services. The four terms around it differ by scope, and scope makes them easy to tell apart. Microsoft keeps definitions in the BI tool, Snowflake in the warehouse, and Databricks in the catalog. Four stages sit between an operational record and an agent’s answer.
A metrics layer tells you how to calculate a number, and a semantic layer tells you what the data means and who may see it.
Why nobody agrees on what a semantic layer is
Vendors, analysts, and practitioners use the term differently, and the disagreement is loud enough to shape the search results.
Search the term, and you find something unusual. The ranked pages define it confidently. The social posts beneath them argue about it.
Some practitioners describe the phrase as a way for data vendors to label what they are selling. Others question the layer entirely, arguing that strong transformation models already do the work. A third group says it’s not a layer at all.
Vendors disagree too, and the pattern is consistent. Each defines the term from where its own product sits in the stack.
A warehouse company defines it as something the warehouse holds. A BI company defines it as something the BI tool holds. A transformation company defines it as something the transformation layer produces.
None of those definitions is wrong. Each describes one valid place to put the definition, but frames it as the only place.
Every definitional page states its version as settled, which is why buyers arrive with four definitions and no way to choose.
That confusion now has a cost, since agents query the same data. A person who reads two definitions picks one. An agent reads whichever definition your platform holds.
Semantic layer, metrics layer, semantic model, ontology: what separates them
The four terms differ by scope, and scope is the axis that makes them easy to tell apart. A metrics layer covers calculation. A semantic layer covers calculation, meaning, and permissions. A semantic model is one tool’s version of that layer. An ontology sits above both as a specification.
| Term | What it defines | Distinguishing property |
|---|---|---|
| Metrics layer | Calculation logic | How a number is computed |
| Semantic layer | Metrics, entities, relationships, access | What data means and who sees it |
| Semantic model | One tool’s implementation | A vendor artifact |
| Ontology | Concepts and relations | A specification, not an implementation |
| Knowledge graph | Relationships across a domain | How things relate, not how much |
The metrics layer distinction is the cleanest of the four. It answers how to compute revenue. It stays silent on what an enterprise customer is, or who may see the number.
An ontology is the specification, and a semantic layer is the implementation built from it.
A fifth term now circulates alongside these four. The context layer describes the same governed tier with the agent use case attached, and several vendors have adopted it recently.
Treat it as positioning, not a new category. The scope test still applies.
A neutral reference point also exists. Apache Ossie, launched as the Open Semantic Interchange by Snowflake, Salesforce, and dbt Labs, moved to the Apache Software Foundation. It defines a JSON and YAML format that any tool can read.
Why an agent needs more than table access
Pointed at raw tables, a model rebuilds joins, grain, and metric logic on every prompt it receives. Nothing constrains those choices. The same question asked twice can produce two different numbers, and both arrive with the same confidence.
Give the model a governed set of metrics instead, and the work changes. It selects from definitions someone approved rather than deriving new ones.
Access rules follow the same logic. Applied before a query runs, they remove the possibility of an agent returning data the user cannot see.
Discovery is the other half. An agent has to find the governed definitions before it can use them.
The Model Context Protocol handles that connection. It gives an agent a standard way to discover what a data source exposes and to query it.
The protocol carries the request. The semantic layer decides what the request can reach.
An analyst who guesses wrong asks a follow-up question, and an agent returns the guess as an answer.
We built a private text-to-SQL agent that queries a governed manufacturing schema with more than 1,100 tables, each with 60 to 70 columns. Response time fell from 120 to 150 seconds down to 5 to 7 seconds. The governed structure made that possible, since the agent had a defined path rather than an open schema.
Where the definitions live: three platform patterns
Microsoft keeps definitions in the BI tool, Snowflake in the warehouse, and Databricks in the catalog. Each platform ships a native semantic capability. What differs is where the artifact sits, which decides what inherits the definitions and what rebuilds them.
| Microsoft | Snowflake | Databricks | |
|---|---|---|---|
| Artifact | Semantic model | Semantic view | Metric view |
| Where it lives | BI tool and Fabric workspace | Warehouse schema object | YAML in Unity Catalog |
| Governed by | Workspace and row-level security | RBAC, auditing, time travel | Unity Catalog, with lineage |
| What reaches it | Reports and Copilot | Cortex Analyst | Genie Agents |
Where definitions live determines which tools inherit them and which rebuild them.
Microsoft: definitions inside the BI tool
Power BI semantic models hold tables, relationships, and measures, and Microsoft renamed them from datasets. The model sits in the Power BI or Microsoft Fabric workspace.
It carries relationships, DAX measures, and row-level security. Reports read it directly.
Copilot in Power BI reads the semantic model, not the tables beneath it. How well the model is described shapes what Copilot returns.
Anything outside that workspace reaches the definitions through the workspace rather than through the warehouse. That places the BI tool on the query path for every consumer.
Snowflake: definitions inside the warehouse
Snowflake semantic views are schema-level objects, so the definitions sit beside the data itself. It stores the semantic information natively rather than in an external file.
A semantic view encapsulates relationships, dimensions, facts, and metrics. It works with SQL, role-based access control, auditing, and time travel.
Cortex Analyst reads those views to answer natural-language questions.
Databricks: definitions inside the catalog
Databricks metric views are written in YAML and registered in Unity Catalog alongside standard views. They hold measures, dimensions, relationships, and metadata.
Unity Catalog governs access and tracks lineage across everything that reads them. Agent metadata adds display names, formats, and synonyms, which improves how language models interpret the fields.
Those synonyms import automatically into Genie Agents, formerly called Genie Spaces. Metric views are a recent addition and remain in preview.
The pipeline work beneath all three is set out in the data engineering work that makes AI deployment possible.
From source systems to agent: the reference architecture
Four stages sit between an operational record and an agent’s answer, and each one guarantees something different. Skipping a stage does not remove it. The work moves downstream, and the agent performs it without supervision.
| Stage | What it holds | What it guarantees |
|---|---|---|
| Source systems | Operational records | Nothing about meaning |
| Modeled data | Tables shaped for analysis | Structure, not definition |
| Governed semantics | Metrics, entities, access rules | One definition per concept |
| Agent interface | The protocol the agent queries | Selection from a governed set |
Source systems record what happened. They carry no view on what a term means across the business.
Modeled data fixes shape. Tables get joined, cleaned, and organized for analysis. Two teams can still read the same table and compute revenue differently.
A modeled table guarantees structure, and only the semantic tier guarantees one definition per concept.
The agent interface is where the constraint becomes enforceable. The agent asks for named metrics rather than composing SQL against tables.
We documented that path in a governed Snowflake Cortex agent platform we built. The agent moves from Cortex Agent to semantic view to database tables, and never reaches raw tables directly.
What breaks when the semantic tier is missing
Skip the semantic tier and the architecture still functions. The agent reaches modeled tables and returns answers.
What disappears is the guarantee. Two questions about the same measure can resolve through different join paths and produce different numbers.
Neither answer is flagged. Both look complete, and the discrepancy surfaces later, usually when someone compares two reports in a meeting.
What to settle before agents touch your analytics
Five decisions determine what an agent can answer correctly, and you make all five before deployment. Each one closes a gap the agent would otherwise fill on its own.
- Agreed metric definitions: which measures have one approved calculation across every team. Start with the ten metrics that appear in board reporting, since those carry the most exposure.
- Resolved entities: how a customer or product is identified consistently across systems. An account in the CRM and an account in billing are frequently different records.
- Query-time access rules: which permissions apply as the query compiles rather than after. Filtering results afterward leaves the data exposed during processing.
- Scoped questions: which topics the agent answers, and which it declines. An agent with no boundary attempts every question, including ones your data cannot support.
- Named authoritative sources: which system wins when two hold different values.
The fifth is where most estates stall. Finance and sales frequently define revenue differently, and both definitions are correct inside their own context.
A definition two teams dispute becomes an answer the agent delivers with confidence.
Data readiness sits underneath all five, and we cover it in data quality management for AI agents. Building the layer that carries these decisions is part of Xavor’s agentic AI development services.
Settle the definitions before the agents arrive.
An agent inherits whatever meaning your data platform already carries, including the parts nobody agreed on.
The five decisions above are governance work, not engineering work, and they take longer than the build. Teams that settle them first deploy agents that answer correctly. Teams that skip them deploy agents that answer quickly.
Most BI models were built for people who could ask a follow-up question. An agent cannot, so it takes the first definition it finds. If you want to check yours against what an agent would need, [email protected] reaches our data team.
FAQs
A semantic layer holds metric definitions, entity definitions, relationships, and access rules in one governed place. Dashboards, analysts, and AI agents read from it, so the same question resolves the same way regardless of which tool asks.
Without one, a model rebuilds joins and metric logic on every prompt, producing different answers to the same question. A semantic layer gives the agent approved definitions to select from and applies access rules before the query runs.
No. An ontology specifies concepts and how they relate. A semantic layer implements those concepts against actual data, adding calculation logic and access control. The ontology describes the model; the semantic layer runs it.