Semantic layer, metrics layer, knowledge layer, context layer: what do they all mean?
Four terms, overlapping definitions, different communities. A clear map of what each term means, where it comes from, and which one you actually need.
TL;DR
Four terms — semantic layer, metrics layer, knowledge layer, context layer — are circulating in overlapping communities with overlapping definitions. They are not the same thing, but they are converging. All four are trending toward the same underlying need: giving AI systems enough structured knowledge to produce useful output instead of generic narration. This post maps each term clearly and explains which one you actually need.
If you've been following the data and AI conversation for the last two years, you've encountered at least three of these terms used almost interchangeably. They are not interchangeable. They come from different communities, solve different problems, and carry different assumptions about what sits at the other end of the pipe.
This post is a map. Not an opinion piece about which term is best — a reference for what each one means, where it came from, and how they relate.
Semantic layer
Origin: Business Objects, circa 1990s. The term was coined to describe the abstraction between a relational database and a business user. Instead of writing SQL, users interacted with business concepts ("revenue," "customer," "region") that the semantic layer translated into the correct queries.
Modern usage: Adopted by the data engineering community. dbt, Cube.js, LookML (Looker), and AtScale all implement semantic layers. The modern version sits between a data warehouse and downstream consumers (BI tools, notebooks, APIs) and ensures that metric definitions are consistent regardless of who queries the data or which tool they use.
What it does: Maps business terms to data structures. "Revenue" always compiles to the same SQL, regardless of whether it's queried from a Tableau dashboard, a dbt model, or an API call. The primary value is consistency — making sure every stakeholder sees the same number.
Assumption: You have a data warehouse. The semantic layer abstracts queries against that warehouse. If you don't have a warehouse, the traditional semantic layer doesn't apply.
Key tools: dbt Semantic Layer, Cube.js, AtScale, LookML, MetricFlow.
Metrics layer
Origin: Emerged as a more specific term within the data engineering community around 2021-2022, partly driven by dbt's work on MetricFlow. The argument was that the "semantic layer" had become too broad — it meant everything from column descriptions to access control. "Metrics layer" focused on the core problem: defining metrics.
Modern usage: A subset of the semantic layer focused specifically on how metrics are calculated. What is the formula for revenue? How do you compute churn? What's the definition of "active user"? The metrics layer answers these questions once, and every downstream consumer inherits the answer.
What it does: Stores canonical metric definitions. Revenue = sum of order_total where status != 'cancelled' and refund_amount = 0. Churn = count of accounts where subscription_status changed from active to cancelled in the period. These definitions live in one place and propagate everywhere.
Relationship to semantic layer: The metrics layer is the most important subset of the semantic layer. Some people use the terms interchangeably, which is technically imprecise but practically harmless — the metrics layer is the part of the semantic layer that most teams actually care about.
Key tools: dbt MetricFlow, Cube.js metrics, Transform (acquired by dbt Labs), Headless BI.
Knowledge layer
Origin: Knowledge management and enterprise AI. The term has roots in knowledge graphs, ontologies, and enterprise search — fields that predate the current AI wave by decades. More recently, data catalogs and governance platforms have adopted the term.
Modern usage: A broader structure that stores not just metric definitions but domain knowledge, relationships between concepts, rules, and institutional context. Where a metrics layer knows how to calculate revenue, a knowledge layer also knows that revenue from enterprise accounts behaves differently than revenue from SMB accounts, that Q4 seasonality affects comparisons, and that the team redefined "active user" in March.
What it does: Stores structured domain knowledge. This includes metric definitions (overlap with metrics layer) but extends to relationships between entities, business rules, analysis heuristics, and contextual knowledge that an analyst would carry in their head.
Key players: Atlan, Alation, Collibra (data catalog/governance space), plus enterprise AI platforms that build knowledge graphs for domain-specific reasoning.
Relationship to semantic layer: The knowledge layer is a superset. It includes everything the semantic layer does, plus domain knowledge that goes beyond metric definitions. The semantic layer tells you what "revenue" means in SQL. The knowledge layer tells you what revenue means in the context of your business.
Context layer
Origin: The most AI-native of the four terms. It emerged from the practical challenge of making LLMs useful for specific tasks — the realization that a model needs situational information, not just general knowledge, to produce relevant output.
Modern usage: The information provided to an AI system for a specific task at a specific moment. Current targets, recent decisions, relevant documents, the Slack conversation from last Tuesday where the team discussed the metric. Context is situational and ephemeral in a way that the other three layers are not.
What it does: Provides the AI with "what's true right now" for a given analysis. The quarterly target is $1.5M. The team decided last week to pause the Meta campaign. The CFO mentioned in a meeting that Q3 hiring is frozen. This information changes constantly and applies to specific analyses, not all analyses.
Relationship to knowledge layer: The context layer is the situational complement to the knowledge layer's persistent store. Knowledge is "CPC spikes on holidays are normal for Google Ads." Context is "the team decided yesterday to increase the Google Ads budget by 30%."
The comparison table
| Dimension | Semantic layer | Metrics layer | Knowledge layer | Context layer |
|---|---|---|---|---|
| Origin | BI (1990s) | Data engineering (2021+) | Knowledge management | AI/LLM era |
| Scope | Business terms → data | Metric definitions | Domain knowledge + rules | Situational information |
| Persistence | Permanent | Permanent | Persistent, evolving | Ephemeral, per-task |
| Requires warehouse | Yes (traditional) | Yes (traditional) | No | No |
| Primary consumer | BI tools, SQL | BI tools, APIs | AI models, analysts | AI models |
| Example | "Revenue = SUM(order_total) WHERE..." | "Churn = accounts cancelled / active" | "AOV-driven growth masks order declines" | "Q2 target is $500K per the planning doc" |
| Key tools | dbt, Cube.js, LookML | MetricFlow, Transform | Atlan, Alation, Collibra | RAG systems, AI analytics |
The convergence
Here is what is actually happening: all four terms are converging toward the same need. Every team building AI-powered analytics is discovering — independently and often painfully — that the model needs structured knowledge to be useful. What they call that knowledge depends on which community they come from.
Data engineers call it a semantic layer. Metric-focused teams call it a metrics layer. Enterprise AI teams call it a knowledge layer. AI product builders call it a context layer.
They are all circling the same object: the thing between raw data and useful AI output.
The convergence is accelerating because AI is the new primary consumer of structured knowledge. A dashboard doesn't need to know that AOV-driven growth is fragile — the human reading the dashboard brings that knowledge. An AI model does need to know it, because without that knowledge, it produces a confident, professional, and misleading summary.
Which one do you need?
The honest answer: elements of all four.
You need metric definitions (metrics layer) so the AI knows what the numbers are. You need domain expertise (knowledge layer) so the AI knows how to analyze them. You need business context (context layer) so the AI knows what matters to your team right now. And you need all of this consistently applied (semantic layer) so the output is reliable across every report and every analysis.
In the five-layer model Chartcastr uses, the first two layers (metric definitions and domain expertise) map to the metrics layer and knowledge layer. Layer three (business context) maps to the context layer. Layer four (institutional memory) extends the context layer with historical conversation data. Layer five (cross-source intelligence) is the genuinely new capability that doesn't map cleanly to any of the four traditional terms.
If you're choosing a tool, don't ask which term it uses. Ask what knowledge it encodes, whether that knowledge is per-provider or generic, and whether it includes your business context or just the data source context. The terminology is secondary. The coverage is what determines whether the AI output is useful.
Further reading
For the full breakdown of how these layers work in practice, see What is a semantic layer, and why does your AI analytics need one?. For the case that most teams don't need a warehouse to benefit from a semantic layer, see A semantic layer for the 90% who do not have a data warehouse.
