Few concepts in data and analytics are talked about more, and understood less, than the semantic layer. We recently had the opportunity to speak to the team at Dresner Advisory Services and provided an update on our journey with Codd AI. I have known some of their team for decades since my Business Objects days. And of course semantic layers were then central to our discussion as it remains today. But we all agreed that listening to the data and analytics market today, you might conclude that everyone has a semantic layer.
Today, nearly every vendor claims to have one:
- BI tools say they have semantic layers
- Cloud data platforms say their catalogs are semantic layers
- Metric stores, YAML files, and glossaries are now labeled semantic layers
Yet despite all this "semantic" innovation, business users still struggle to get consistent answers, analysts still rebuild logic repeatedly, and GenAI systems still hallucinate.
The problem is not the semantic layer itself. The problem is that the term has been stretched to cover fundamentally different things, and in doing so, has lost its meaning.
To make sense of this, we need to look at both what vendors mean by semantic layers and the deeper architectural split (and purpose) between universal and domain-specific approaches.
The Semantic Layer Spectrum: From Translation to Understanding
Not all semantic layers are created equal. In practice, they sit along a spectrum.
1. Traditional BI Semantic Layers: SQL Translation, Not Context
At one end of the spectrum are traditional BI tools.
These semantic layers:
- Rename tables and columns with business-friendly labels
- Define joins and basic calculations
- Primarily exist to generate SQL
They help analysts query data faster, but they encode no real business context.
They do not capture:
- Why a metric exists
- When a definition changes
- Which assumptions apply
- How meaning differs by domain
These layers translate queries. They do not teach systems, or users, how the business works.
2. Cloud Data Platforms: Governance Wearing Semantic Labels
Further along the spectrum are cloud data platforms that increasingly describe governance capabilities as semantic layers.
Examples include:
- Centralized catalogs
- Glossaries and classifications
- Metric definitions stored in configuration files (mostly YAML)
These capabilities are essential infrastructure. But they are governance artifacts, not analytics artifacts.
The limitations are structural:
- Business logic is manually encoded and brittle
- Metrics are static and slow to evolve
- Context lives in documents, not systems
- AI has no ability to reason about intent or nuance
Calling this a semantic layer may be convenient, but it is more accurately managed metadata.
Where the Conversation Breaks Down: Universal vs. Domain Semantics
This leads to a second, and more important, distinction that often gets lost: Universal semantic layers vs. domain-specific semantic layers.
Numerous vendors (and customer organizations) implicitly argue for a single, universal semantic model, an "uber layer" that spans the entire enterprise.
On paper, this sounds elegant. In practice, it serves a very different purpose than a contextual or domain specific semantic layer.
Universal Semantic Layers: Alignment Over Action
Universal semantic layers are designed to:
- Standardize definitions across domains for the enterprise
- Provide a shared vocabulary
- Support governance, compliance, and consistency
They are optimized for agreement, not execution.
To achieve enterprise consensus, these layers must:
- Strip away domain nuance
- Default to lowest-common-denominator definitions
- Change slowly through negotiation and committees
As a result:
- Analysts rarely query them directly
- Business users bypass them
- AI systems cannot rely on them for precise reasoning
They are valuable, but primarily as documentation and governance assets, not analytics engines.
Domain-Specific Semantic Layers: Context That Drives Decisions
Domain-specific semantic layers solve a different problem. They are built around how a domain actually operates: Sales, Finance, Operations, Marketing, each with its own logic, metrics, and exceptions.
These layers:
- Encode domain knowledge, not just definitions
- Preserve nuance instead of flattening it
- Evolve at the speed of the business
- Power real analytics and GenAI experiences
This is where analytics, and AI, actually happen.
An uncomfortable truth: The more "universal" a semantic layer becomes, the less analytically useful it is. And Analytics and GenAI require contextual specificity, not compromise.
Why Data Mesh Made This Inevitable
Architectures like data mesh didn't create this reality. They exposed it.
Data mesh encourages:
- Domain ownership
- Domain-specific data products
- Decentralized evolution
What it does not solve on its own is consumption.
Without a domain-specific contextual layer:
- Data products remain technical assets
- Business users are locked out
- GenAI systems hallucinate or misinterpret results
In our blog Business Data Products and Contextual Semantic Layers: The Perfect Neural Pairing we discuss in detail how the contextual semantic layer powers user adoption of data products.
Codd AI: From Semantic Layer to Contextual Intelligence
Codd AI was built on a simple observation:
GenAI needs a unified contextual knowledge base to operate correctly if it is going to add consistent and trusted value. Business understanding cannot be hand-coded or added by individual users in conversational queries.
Codd AI unifies:
- Technical metadata (schemas, lineage, models)
- Business knowledge (KPIs, rules, assumptions)
- Domain relationships and hierarchies
- Historical analytical intent
And crucially:
- Uses GenAI to automate data modeling, metric creation, and semantic enrichment
- Continuously evolves context as domains change
The result is not just a semantic layer. It is a domain-specific corpus of business understanding that humans and AI can reason over.
Why Language Matters: Moving Beyond "Semantic Layer"
Because the term has been diluted, calling Codd AI "another semantic layer" undersells what it does.
A better framing is to distinguish:
- Technical semantic layers - translation and governance
- Contextual semantic layers - reasoning and decision-making
Or to elevate the category entirely at some point we might need to determine some other name entirely:
- Business Context Layer
- Domain Intelligence Layer
- Business Knowledge Layer
- Analytical Reasoning Layer
Each signals something fundamentally different from legacy semantics.
Closing Thought
A clean way to summarize the discussion might be:
Universal semantic layers help organizations agree on language.
Domain-specific contextual layers help organizations make decisions.
It is clear that the Universal Semantic Layer serves a different purpose than the Domain Specific Semantic Layer. Most organizations might find they will have both approaches in a truly mature data-driven organization. But to unleash the analytical power of GenAI, it cannot and will not succeed (at least in the near term) without the domain specific contextual semantic layer.
AI cannot reason over glossaries, labels, or YAML files.
It needs context.
It needs domain knowledge.
It needs systems designed for understanding, not documentation.
While your organization might be on the fence as to the universal semantic layer, there is massive value for organizations to standardize on a single platform across multiple domains and use cases.
Codd AI has been designed with that enterprise objective in mind. It provides a highly standardized way for you to generate the domain specific contextual semantic layer and at the same time will take 50-70% of the manual effort out of that process. If you are embarking on your AI analytics we would love the opportunity to chat with you and your team. If you are interested in learning more, you can schedule 30 minutes for a quick overview presentation and demo.