Semantic Layer vs. Business Glossary: What Each Holds

---

Use a business glossary to approve what a term means and a semantic layer to compute it; most data teams need both, linked. A glossary term and a semantic-layer metric can share the name “net revenue” and still count different things, and when they drift, a governance lead ends up explaining why two dashboards and an AI agent report three revenue numbers. Atlan, the AI Context Platform, links each approved term to the columns and supported semantic assets that implement it, traces lineage (the record of which data feeds which) to the dashboards and agents that consume it, and serves that path to agents over MCP, the Model Context Protocol agents use to call tools. The definition stays with its business owner and the calculation stays in the engine that runs it.

Side by side:

Dimension	Business glossary term	Semantic layer metric
Primary job	Record approved meaning and ownership	Apply defined calculation rules for a given model version
Unit of change	Owner-approved definition change	Code change, usually reviewed in Git and tested in CI
Scope	Any business concept, metric or not	The entities, dimensions, and metrics the model covers
Ownership	Named owner and steward on the term	Engine-specific owner fields, such as dbt groups or object owners
Synonyms	Governed labels of record	Model-specific hints for AI tools, where supported
Reach	Concepts linked to assets across systems	Defined once per semantic layer and served to the tools that layer integrates with
Failure mode	Approved words with no executable logic	Correct computation of an unapproved meaning

---

Semantic layer vs. business glossary: what each one holds

A business glossary holds approved business meaning.

A term records its definition, scope, exclusions, owner, steward, certification, synonyms, related concepts, and links to the assets that carry it. Glossary designs often borrow vocabulary concepts from W3C SKOS and registry concepts from ISO/IEC 11179, and a glossary covers non-metric terms, such as what counts as an active customer, as well as metrics.

A semantic layer holds executable metric logic: entities, joins, dimensions, measures, filters, and aggregations that an engine turns into queries. dbt MetricFlow and LookML both document this model-to-query role. Semantic layers carry descriptions, labels, and often synonyms too, which help a person or an agent pick the right metric. The executable logic still decides the number that comes back.

A semantic layer versus data catalog comparison covers how executable models relate to the catalog’s wider inventory, and the context layer, data catalog, and semantic layer comparison shows how the three divide the work. The question that matters for a governance lead is narrower: does each approved term point to the metric that implements it?

---

The same word in both: “net revenue” side by side

One term, “net revenue”, shows the gap. Here it is as an approved glossary term and as two metric records meant to implement it:

Field	Glossary term	dbt metric	Snowflake semantic-view metric
Identity	Net revenue, USD, external reporting	net_revenue_usd	net_revenue_usd
Meaning	Recognized revenue after refunds and discounts; excludes intercompany	Description: “Net revenue”	Description: “Net revenue”
Accountability	Finance owner; certified	Set through a dbt group owner or meta, if the team adds one	Not set in this excerpt
Calculation	Invoice amounts after approved adjustments	Sum of amount_usd	Sum of amount_usd
Time	Recognition period	invoice_date	Not set in this excerpt
Synonyms	Net sales	None set	“net sales”, “sales”

The dbt metric

In dbt Core v1.12, generally available since August 2026, semantic annotations and simple metrics sit inside the model definition. The meta keys below are illustrative: dbt accepts any key-value pairs there.

models:
  - name: fct_invoices
    description: "Invoices table containing USD amounts"
    semantic_model:
      enabled: true
      name: finance_invoices
    agg_time_dimension: invoice_date
    columns:
      - name: invoice_id
        entity:
          name: invoice
          type: primary
      - name: invoice_date
        granularity: day
        dimension:
          type: time
    metrics:
      - name: net_revenue_usd
        label: "Net revenue"
        description: "Net revenue"
        type: simple
        agg: sum
        expr: amount_usd
        config:
          meta:
            glossary_term: net-revenue-usd-external
            glossary_term_version: 3

This metric sums every amount_usd value in fct_invoices. Nothing in the excerpt applies the refund, discount, or intercompany rules the term describes. In a simple event model, a $100 invoice followed by a refund row of minus $20 contributes $80, and still contributes $100 if an upstream filter drops the refund row. The model has to implement the approved adjustments; a label on a sum changes nothing.

The Snowflake semantic-view metric

A table-level metric in Snowflake semantic views holds its own description, expression, and synonym list. Row-level values are declared as facts, and metrics aggregate them:

name: finance_analytics_view
description: "Semantic view for corporate finance"
tables:
  - name: invoices
    description: "Invoices table containing USD amounts"
    base_table:
      database: ANALYTICS
      schema: FINANCE
      table: FCT_INVOICES
    facts:
      - name: amount_usd
        expr: amount_usd
        data_type: NUMBER
    metrics:
      - name: net_revenue_usd
        expr: SUM(amount_usd)
        description: "Net revenue"
        synonyms: ["net sales", "sales"]

Both excerpts are illustrative, not complete deployable models. The glossary term and two metrics now describe one concept in three records, each with its own change process. Only the dbt record carries a pointer back to the term, and a pointer only claims agreement; a test is what shows it. Add Unity Catalog metrics and there is a fourth record to reconcile.

---

How each format represents meaning and math

Every format mixes descriptive fields with executable logic. What differs is where it puts meaning, where it puts math, and whether it records business approval at all.

dbt Semantic Layer and MetricFlow

MetricFlow “handles SQL query construction,” according to dbt’s MetricFlow documentation, and builds joins from the entity types declared on each model. The semantic-model specification places description, label, and meta beside entities, dimensions, and metrics, and dbt groups give every group of models and metrics a named owner. The dbt Semantic Layer gives those definitions an execution path. Approval of the business meaning is recorded wherever the team chooses: a meta key, a pull-request review, or a linked glossary term.

LookML

Google Cloud’s LookML documentation says LookML describes “dimensions, aggregates, calculations, and data relationships,” and Looker uses that model to construct SQL. Model files say which tables to use and how to join them; view files describe how each field is calculated. Whether LookML or a universal semantic layer serves the query, the approved definition still has to point at the field that computes it.

Snowflake semantic views and Databricks metric views

Snowflake’s YAML specification places description, synonyms, verified_queries, and module_custom_instructions beside metric expressions. Databricks’ metric view documentation describes synonyms, display names, and formatting rules added to improve agent accuracy. These fields help an agent interpret a question, and they also create vocabulary in Unity Catalog’s semantic layer or in Snowflake that has to stay consistent with the glossary.

Apache Ossie

Apache Ossie, formerly Open Semantic Interchange (OSI), is a specification for exchanging semantic model definitions between tools. In the core specification, currently the draft version 0.3.0.dev0 on the main branch, a metric has a required name and expression plus optional description, datatype, and ai_context, with vendor-specific state carried in nonportable_extensions. dbt v1.12 can read Ossie documents alongside native semantic models. A portable file moves a definition between engines; the record of who approved its meaning comes from whatever governs the term.

SKOS and ISO/IEC 11179 on the glossary side

The W3C SKOS reference, a 2009 Recommendation, defines prefLabel, altLabel, definition, and broader, narrower, and related links for organizing vocabulary. ISO/IEC 11179-1:2023 is the framework part of a standard for metadata registries. Both describe meaning and how to register it; metric execution belongs to a semantic engine. An ontology and a semantic model can also represent related concepts without being interchangeable, and the ontology and semantic-layer boundary explains where modeling scope ends.

---

Where glossaries and semantic layers overlap, and why the copies drift

Overlap is useful until two copies of one definition change on different schedules.

Semantic layers add descriptions and synonyms so tools pick the right metric. Glossaries add formula summaries so stewards can interpret a metric without reading code. Each copy is reasonable on its own.

The trouble starts when the copies diverge. Suppose the glossary defines “sales” as bookings, while a semantic view lists “sales” as a synonym for recognized revenue. Both pass their own validation, and an agent sees two mappings for one word. Snowflake’s own semantic view modeling guidance adds a second reason for care: it says “synonyms generally add little accuracy” with current models and that “auto-generated synonyms often reduce semantic view quality.” Treating semantic views as materialized context forces the question of which record controls vocabulary.

For connected systems of semantics, the decision is property by property: the glossary is authoritative for meaning, scope, owner, and approval; the semantic model is authoritative for expression, grain, joins, and filters.

---

Five ways glossary and semantic layer definitions drift

Drift starts when one side changes without a review of the other. These five cases are the ones a governance lead will recognize:

• Formula moves, words stay. An engineer excludes reseller invoices in a pull request. Finance’s glossary still includes reseller revenue. Tests for the new code pass, and the business definition now describes the old calculation.
• Words move, formula stays. Finance approves excluding intercompany sales from next quarter. The semantic model keeps counting them because no implementation ticket follows the approval.
• Synonym forks. One agent-facing model maps “sales” to revenue; another maps it to bookings. Context drift detection has to inspect the mappings as well as the descriptions.
• One term, many formulas. USD revenue and local-currency revenue share one term. An agent sees a certified term, no explicit variant, and picks a calculation in the wrong unit.
• One metric, many engines. A metric is corrected in dbt but not in a Power BI semantic model. The glossary links only to one dashboard, so the second implementation sits outside its review path.

Steward approval and code review are separate lifecycles. One common cause of context drift in AI agents is that neither process asks for evidence from the other.

---

How to link a glossary term to a semantic layer metric

Make the link something a reviewer can check.

A report link says where a number appears; the metric, its source columns, and a passing test say what produced it. Use this chain:

Term → metric definition(s) → source columns → lineage → consumers, including dashboards and agents.

An approved term points to the metric that implements it, the columns it reads, and the consumers that use it, and a change on either side triggers review. Source: Atlan.

Six rules that keep the link accurate

Six rules keep the chain accurate as definitions and implementations change. The first three shape the record itself:

• Give each distinct meaning its own term. When two implementations can return different numbers for the same question, because of unit, scope, or audience, they are different terms. Name them explicitly, such as “Net revenue, USD, external reporting” and “Net revenue, local currency, operational”, give them a shared alias for search, and relate them to each other. Refactoring code that returns the same number is not a new term. Managing KPI definitions in a business glossary covers the term structure.
• Keep the approved meaning with its owner. Record scope, exclusions, synonyms, effective date, and the accountable owner on the term. A formula field on the term is a human-readable summary reviewed at certification; the engine’s expression is the one that runs.
• Link at the column level, and type the link. Link the term to the authoritative metric and the source columns it reads. Lineage then shows impact: which dashboards, models, and agents depend on those columns. Data lineage for AI shows which metrics depend on a column, and two metrics that share an input column can still return different numbers.

Rules that keep the link current

The other three make sure a change on either side gets noticed:

• Certify meaning and implementation together. Test exclusions, units, time grain, and joins against fixed examples. If the term excludes intercompany revenue, a test invoice marked intercompany must contribute zero. Lineage served over MCP makes the dependencies inspectable; the test is what shows the arithmetic matches the meaning.
• Make a change on either side reopen the link. Put the term ID and version in the metric’s metadata, as in the dbt meta keys above, and the metric version on the term. A CI check that fails when the term version is newer than the one the metric declares turns “formula moves, words stay” into a failed build. The context layer for governance teams carries that evidence across the two workflows.
• Export only tested synonyms. Push approved aliases into a model’s synonym field only where testing shows they help, and scope them by domain. Test “sales” against bookings and recognized revenue first, and have the agent ask for clarification when both meanings remain valid.

A worked change, step by step

A worked change shows the loop. Term version 3 maps to metric version 12. A pull request adds the reseller exclusion, the CI check flags the version mismatch, and the link moves to pending review. Finance approves term version 4 with the new exclusion, the fixture tests pass, and the metric ships as version 13 on the term’s effective date. Until then, an agent asking for net revenue gets version 12 and the note that a change is pending.

---

What AI agents need from each, and what happens when one is missing

An agent needs the glossary to resolve what the user means and the semantic layer to calculate it.

Correct SQL can still answer the wrong business question, which is why a semantic layer for AI agents works best with an approved meaning attached. Take away the approved meaning and the agent may calculate gross bookings when Finance asked for recognized revenue, with sound math that answers a question nobody asked. Take away the governed calculation and the agent understands net revenue but writes its own joins and filters, so the meaning is right and the implementation is nobody’s.

Gartner puts semantics at the center of agent accuracy. In a May 2026 press release, Rita Sallam, Distinguished VP Analyst at Gartner, said: “Agentic AI outcomes depend on context including semantic representations of data.” Gartner also advised data and analytics leaders to “establish a context layer as a core component of their D&A infrastructure.” According to Gartner (2026), organizations that prioritize semantics in AI-ready data will increase agentic AI accuracy “by up to 80%” and “reduce costs by up to 60%” by 2027. Those are forecasts, not measured results.

Research on ambiguity points the same way. In the AMBROSIA benchmark, Saparina and Lapata found that ambiguity in questions persists “even when the database context is provided,” and that even advanced models struggled to identify and interpret it. Valid columns do not tell an agent which approved meaning of “revenue” the user intended.

Test interpretation and calculation separately in enterprise text-to-SQL, and when choosing between text-to-SQL and a semantic layer. The same applies to Cortex Analyst and text-to-SQL: cutting AI agent hallucination includes rejecting a plausible answer built from the wrong metric.

---

How does Atlan link meaning and computation for AI agents?

Atlan keeps the definition and the calculation in their own systems and records the tested path between them.

The glossary term holds the definition, owner, certification, and, for a metric, its formula and data sources. It links the term to the tables and columns that implement it, traces lineage through supported semantic assets to downstream consumers, and holds those relationships in its Enterprise Data Graph. This is how context engineering complements the semantic layer: the context layer supplies the approved meaning and provenance, and the existing metric engine calculates the result.

What each Atlan capability does in the chain

Capability	What it does	Why it matters here
Business glossary	Terms carry definitions, owners, certification status (draft, verified, deprecated), related terms, and links to assets down to columns.	Keeps approved meaning and synonyms with an accountable owner.
Metric terms	Each metric is a term with a formula field, data sources down to tables and columns, an owner, and a certification status, with one term per distinct formula.	Gives each metric one governed record that points to the assets used to compute it.
Context Agents	Lexis builds the glossary from column patterns, Nexus links columns to business terms, Sage finds conflicting metric definitions, and Orion maps the ontology connecting domains and metrics.	Creates term-to-column links and surfaces conflicting definitions for a steward to resolve.
Data lineage	Column-level provenance built from SQL parsing, native integrations, OpenLineage ingestion, and custom lineage.	Shows which calculations, dashboards, and agents a change affects.
Semantic assets	Catalogs Databricks metric views and Power BI semantic models as semantic assets.	Brings platform-native metric definitions into the same graph as business terms and lineage.
Context Engineering Studio	Reads existing data, SQL queries, and BI dashboards to draft a semantic layer that domain experts refine and test against generated questions.	Gives owners a way to check definitions and relationships before agents consume them.
Context Lakehouse and MCP	Delivers context through MCP, A2A, SQL, and APIs. MCP tools search assets by glossary term, return an asset’s linked terms, and traverse lineage.	Gives agents meaning, linked assets, and provenance before an authorized engine computes the metric.

Where the link reaches agents

For a semantic system not yet cataloged as a semantic asset, link the term to the source columns the metric reads and record the metric’s identifier and version on the term. The Atlan MCP server then lets an agent read the approved meaning and its provenance before choosing a calculation, and serving a semantic layer over MCP still needs an authorized route to the engine that computes the metric. At larger scale, CME Group cataloged over 18 million assets and more than 1,300 glossary terms in its first year with Atlan.

A business context layer keeps the glossary and the semantic layer separate and connected, and a context repository gives agents approved context, with its owner, version, and change history, before the interaction begins. That typed, testable link is what separates a data catalog from a context layer in practice.

---

When to use a glossary, a semantic layer, or both

Use the record that matches the question, and link them when a metric needs both.

A glossary alone fits when the question is about meaning and ownership: a term that is not a metric, such as what counts as an active customer, or a definition that several teams and tools must agree on before anyone writes code. A semantic layer alone fits when one team owns a metric end to end in a single engine and the definition is already settled. Both, linked, fit any metric that an executive report, a regulator, or an AI agent depends on, because that is where an approved meaning and a running calculation have to match and stay matched.

---

Real stories from real customers: Shared language for metrics and AI

---

Where to start: one disputed metric

Pick the metric that already produces two numbers in two meetings.

Write its approved term, link it to every implementation you can find, add the fixture test, and put the term version in each metric’s metadata. Then change one exclusion rule on purpose and watch whether approval, engine logic, the link, and the tests all move together. If they do, repeat the pattern in the next domain as you work through implementing an enterprise context layer. If they do not, the step that failed is the first one to fix.

---

FAQs about semantic layers and business glossaries

1. What is the difference between a business glossary and a semantic layer?

A business glossary records what a business term means, who owns it, and who approved it. A semantic layer encodes how a metric is calculated, as definitions an engine compiles into queries.

2. Do I need a business glossary if I have a semantic layer?

Usually, yes. A glossary covers concepts outside the semantic model’s scope, definitions that span several engines, and the approval record for a meaning. A semantic model on its own covers what that model computes.

3. Can a semantic layer replace a business glossary?

Only for the concepts that one semantic model defines, and only if the team records approval there. Non-metric terms, definitions shared across engines, and the record of who agreed on a meaning still need a governed home.

4. Should metric definitions live in the glossary or the semantic layer?

Keep business meaning and ownership in the glossary and executable logic in the semantic layer. Link the two, and review the link whenever either the approved meaning or the implementation changes.

5. How do you link glossary terms to semantic layer metrics?

Create one term for each meaning that can return a different number, link it to the authoritative metric and its source columns, and record the term ID and version in the metric’s metadata. Lineage then shows which dashboards, models, and agents depend on it.

6. Why do glossary and semantic layer definitions drift apart?

They change through different processes: glossary terms through steward approval and semantic models through code review. When neither process checks the other, a definition or a formula changes and its linked record does not.

7. What do AI agents need from each?

Agents need the glossary to resolve a user’s words to an approved meaning and the semantic layer to calculate that meaning. They also need evidence that the two still agree, such as a passing test tied to the current versions.

8. Where do synonyms belong?

Keep approved synonyms on the glossary term as the record of what each word means. Copy a synonym into a semantic model’s synonym field only when testing shows it helps, and scope it to the domain where it is valid.

9. Is a semantic layer the same as an ontology or a metrics layer?

No. An ontology represents business concepts and their relationships. A metrics layer focuses on reusable metric calculations. A semantic layer covers metrics plus the entities, dimensions, and joins an engine needs to query them consistently.

10. Does Apache Ossie (formerly OSI) solve the glossary problem?

Ossie standardizes how semantic model definitions move between tools. In the current draft spec, a metric has a required name and expression, optional description, datatype, and ai_context fields, and vendor-specific state in nonportable_extensions. Record approval of the meaning wherever your team governs the term.

11. What is a semantic layer?

A semantic layer is a model that maps business metrics and dimensions to tables, joins, and calculations, so every tool that queries it gets the same result for the same question.

12. What is a business glossary, and how does it relate to an ontology?

A business glossary defines terms in plain language and records who owns and approved each one. An ontology goes further and models typed relationships and rules between concepts so software can reason over them. Many teams start with the glossary and add relationships as agents need them.

13. Can a data catalog replace a semantic layer?

No. A data catalog inventories and describes data assets and their lineage. A semantic layer computes metrics. A catalog can record where a metric lives and which glossary term it implements, but the calculation still runs in the semantic layer.

---

Sources

1. Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending, Gartner
2. About MetricFlow, dbt Developer Hub
3. Semantic models, dbt Developer Hub
4. Add groups to your DAG, dbt Developer Hub
5. dbt Core v1.12 is GA, dbt Labs
6. YAML specification for semantic views, Snowflake Documentation
7. Best practices for modeling semantic views, Snowflake Documentation
8. Unity Catalog metric views, Databricks Documentation (docs.databricks.com/aws/en/uc-semantics/metric-views)
9. Introduction to LookML, Google Cloud Documentation
10. core-spec/spec.md, apache/ossie, GitHub
11. SKOS Simple Knowledge Organization System Reference, W3C
12. ISO/IEC 11179-1:2023, IEC Webstore
13. AMBROSIA: A Benchmark for Parsing Ambiguous Questions into Database Queries, arXiv