A semantic layer is a governed set of business definitions that sits between your data platform and the people, reports and AI systems that use it. It says what "active customer", "net written premium" or "days past due" means, how each is calculated, which tables it comes from and who may see it. Every tool then asks for the metric by name instead of rebuilding it in SQL. For AI on enterprise data, that is the difference between an answer you can defend and one you cannot. This guide is part of our Semantics, RAG & Data Meaning series.
Most firms already have the problem a semantic layer solves. Finance reports one number for deposits, risk reports another, and the branch dashboard shows a third. Each is correct by its own logic. The logic lives in three places, written three ways, and nobody can say which is right without a meeting.
A semantic layer moves that logic into one shared definition. It maps physical tables and columns to business terms, defines how measures are calculated, sets how entities join, and records who owns each definition. Reports, notebooks, applications and AI agents all query through it. Change the definition once and every consumer gets the change.
The idea is not new. BI tools have carried semantic models for decades. What changed is where the layer lives and who uses it. It used to sit inside one BI tool. Now firms want one layer that serves every BI tool, every application and every AI system, which is why the term "universal semantic layer" appears in vendor material.
Why AI Needs a Semantic Layer
A language model asked "what were our deposits last quarter?" has to guess. It has to pick a table, decide which accounts count, choose a date field, and handle currency and closed accounts. It will produce SQL that runs. It may not produce the number finance reports.
A semantic layer removes the guessing. The model, or the agent wrapping it, asks for the metric "total deposits" for "last quarter" and the layer generates the query from the approved definition. Three things follow:
Consistency. The agent's answer matches the dashboard and the regulatory report, because all three use the same definition.
Explainability. Every number traces to a named metric with an owner and a documented calculation. That is what a model risk or audit reviewer asks for.
Access control. The layer can enforce who may see which metrics and at what level of detail, so an agent cannot reach data its user could not.
The same logic applies to retrieval. A retrieval system that pulls documents about "exposure" gets better results when it knows which of five meanings of exposure the user intends. Shared definitions help the retrieval side as much as the query side.
Semantic Layer vs Data Catalog vs Ontology vs Knowledge Graph
Semantic layer, data catalog, ontology and knowledge graph overlap, and vendors use the terms loosely. In practice they do different jobs.
Semantic layer. Defines and computes business metrics consistently. It answers "what is net written premium, and what was it last month?" It holds entities, joins, measures, dimensions and access rules, usually as YAML or SQL definitions with a query engine. Examples include the dbt Semantic Layer, Cube, AtScale, Snowflake semantic views and Databricks metric views.
Data catalog. Finds and describes data assets. It answers "which tables hold policy data, and who owns them?" It holds metadata, owners, lineage, classifications and a business glossary. Examples include Apache Atlas, Collibra, Alation and Unity Catalog.
Ontology. Defines business concepts and how they relate. It answers "is a guarantor a kind of counterparty?" It holds classes, properties and rules, usually written in OWL or RDF. FIBO is the main example in financial services.
Knowledge graph. Stores facts about real entities and their relationships. It answers "which companies does this borrower control?" It holds nodes and edges with properties in a graph database such as Neo4j.
They work best together. The catalog says where data is and who owns it. The ontology fixes what the business concepts mean. The semantic layer turns those meanings into calculations. A knowledge graph holds the connected facts that tables represent poorly, such as ownership chains or referral networks.
What Goes into a Semantic Layer
Whatever the product, a semantic layer holds the same kinds of definitions:
Entities: the business objects, such as customer, account, policy or claim, mapped to physical tables.
Relationships: how entities join, with the keys and the join type, so no consumer has to work it out.
Measures and metrics: the calculations, including filters, such as excluding closed accounts or test policies.
Dimensions: the attributes used to group and filter, such as product line, region or date.
Definitions and owners: a plain-language description of each metric and the person who approves changes.
Access rules: which roles see which metrics, and at what detail.
A metric definition usually looks something like this. The syntax below is illustrative, not any one product's format:
A metric definition names the metric, describes it in plain language, names its owner, and sets the calculation and filters: for example, the sum of balances in USD for open deposit accounts. It also lists the dimensions the metric can be grouped by and the roles allowed to see it.
The value is not the syntax. It is that the definition is versioned, reviewed and owned, like code. When a regulator asks how a reported figure was produced, you show this file and its change history.
Where the Semantic Layer Lives
There are three common places to put a semantic layer. Most estates end up with more than one, which is why portability matters.
Inside the BI tool. Looker's LookML and Power BI semantic models are long-standing examples. They work well when one BI tool dominates. They serve other tools and AI agents less well.
Inside the data platform. Snowflake semantic views store logical tables, relationships, facts, dimensions and metrics as schema objects, and Snowflake's Cortex Analyst and Cortex Agents use them to generate SQL. Databricks metric views in Unity Catalog let you define a metric once and query it from SQL, dashboards, Genie and external BI tools. This keeps definitions next to the data and under the platform's access controls.
As a separate layer. The dbt Semantic Layer, powered by MetricFlow, along with Cube and AtScale, sits between platforms and consumers. This suits firms with several data platforms or several BI tools.
On Cloudera, the same pattern applies to Iceberg tables, with Apache Atlas recording lineage and access policy enforced in the platform. For firms that keep AI inside their own perimeter, the semantic layer is part of private AI on Cloudera, so models query governed definitions without data leaving the environment.
Portability is improving. The Open Semantic Interchange (OSI), started in 2025 by Snowflake, Salesforce, dbt Labs and others, publishes a vendor-neutral format for exchanging semantic models. dbt Labs released MetricFlow under the Apache 2.0 license as part of that work, and in 2026 the project entered the Apache Incubator as Apache Ossie. It is early, but it reduces the risk of locking definitions into one product.
Ontologies and Knowledge Graphs for Regulated Data
A semantic layer handles numbers well. It handles meaning across systems less well. That is where ontologies come in.
Financial services has a head start. FIBO, the Financial Industry Business Ontology, is maintained by the EDM Council, standardized through the Object Management Group, and written in OWL. It defines concepts such as legal entities, contracts, securities and loans, and how they relate. Firms rarely adopt all of it. They use the parts that match their domain as a reference, so that "counterparty" in the risk system and "counterparty" in the KYC system mean the same thing.
Healthcare has its own reference vocabularies, such as clinical terminologies for diagnoses and procedures, and the same principle applies: map local codes to a shared reference before AI reasons over them.
A knowledge graph stores facts using those concepts. In KYC, a graph that links people, companies, addresses and accounts shows ownership chains that would take many joins to find in tables. An AI agent investigating an alert can then walk the graph and cite each link it used.
None of this works without a catalog and lineage underneath. Definitions must point at real, governed data. Our page on data governance for regulated firms covers the catalog, lineage and access policy this depends on.
Connecting AI Agents to the Semantic Layer
An agent should ask the semantic layer for metrics, not write raw SQL against production tables. Two developments make that practical.
First, semantic layers now expose interfaces built for AI. Snowflake's Cortex Analyst reads semantic views. Databricks Genie reads metric views. The dbt MCP server lets AI assistants list and query Semantic Layer metrics through the Model Context Protocol (MCP), either self-hosted or as a service.
Second, MCP gives agents one standard way to reach those tools. That also gives you one place to control them. Route agent calls to the semantic layer through an AI gateway that checks the agent's identity, applies policy and logs every query. The log then records which agent asked for which metric, under which definition version, on whose behalf.
Two rules keep this safe:
The agent inherits its user's access. If a branch manager cannot see another region's deposits, neither can the agent acting for them.
The agent cannot change definitions. Reading metrics and editing them are separate permissions, and editing goes through review.
Building a Semantic Layer: Six Steps
Pick the questions first. Start with the 20 to 30 metrics that drive real decisions or regulatory reports, not every column in the warehouse.
Name an owner for each metric. Usually a business owner, with a data engineer accountable for the implementation.
Write the definitions, including the edge cases. Closed accounts, reversals, currency, late-arriving data. Most disputes live in the edge cases.
Reconcile against current reports. Run each metric and compare it with the number finance or risk publishes today. Explain or fix every difference before anyone relies on it.
Put definitions under version control and review. Treat a definition change like a code change, with tests and approval.
Connect consumers one at a time. BI first, then applications, then AI agents, each through the layer rather than around it.
What Auditors and Examiners Check
Reviewers do not ask whether you have a semantic layer. They ask whether reported numbers and AI answers are traceable and controlled. Expect requests like these:
A list of critical metrics, each with a written definition, an owner and an approval record.
Version history for each definition, showing who changed it, when and why.
Reconciliation evidence between semantic layer metrics and the figures in regulatory and management reports.
Lineage from each metric back to its source systems.
Access rules on metrics and rows, and proof they apply to AI agents as well as people.
Logs showing which metric and definition version an AI answer used.
A change process that tests a definition change against downstream reports before release.
Evidence that AI agents query governed definitions rather than raw tables, or a documented exception where they do not.
A reviewed mapping between business terms and any reference ontology in use.
Monitoring that flags when a metric's results move outside expected ranges.
If you can produce each of these from system records, AI answers built on the layer are ready for review.
The technology choice is the easy part. The hard part is agreeing definitions across finance, risk and operations, reconciling them to reported numbers, and wiring AI agents to use them without bypassing controls. Duczer East provides data and AI consulting for regulated enterprises, including the semantic layer, ontology and knowledge graph that AI answers depend on.
