The Semantic Layer Market Solved Everything Except the One Question That Matters

Every enterprise chasing AI maturity just spent three years and several million dollars solving the wrong layer of the problem, and Gartner's own numbers prove it. 44% of organizations already have a semantic layer live. Another 48% will by 2027. Having one is about to become table stakes — and only 14% of those same leaders trust what's underneath it is actually governed. Build the layer, skip the judgment, ship the confidence gap. That's the trade every one of these rollouts just made.

Same metric. Same quarter. Two different numbers — and no one in the room knows which one to trust.

Here's why the gap survives even a well-built semantic layer: it answers what is the correct formula for this metric and how do we make sure everyone computes it the same way. Every serious platform in the category — Databricks Metric Views, dbt MetricFlow, Purview, OSI, Neo4j, Tableau, Dagster Compass — answers that better than anything the industry has shipped before. But "everyone computes it the same way" and "everyone should be looking at the same number" are not the same claim. The market built the first. It skipped the second, then billed customers for solving both.

Semantics tells a system what a word means. Context tells it which meaning applies right now, to this person, for this decision. No one selling the semantic layer today ships the second one.

The CPG example

Picture a quarterly business review at a mid-size CPG company. The VP of category management opens with a slide: sell-through rate on a flagship SKU is up 6% quarter-over-quarter, a strong reorder signal. Ten minutes later, the trade-promotion finance lead pulls up her number for the same SKU, same quarter: sell-through is flat, maybe soft once the promotional accrual is backed out. Same term. Same product. Same window. Two numbers, and a room full of executives who now have to decide which one to trust before they can decide anything else.

Both numbers could sit inside a perfectly governed Metric View, with clean lineage and a certified badge on each dashboard. That's the problem.

• The category manager's version is trailing-13-week and shipment-based, built to answer "should we reorder" — fast and directionally useful, exactly what a replenishment decision needs.

• The finance lead's version is promo-window-only, tied strictly to point-of-sale scan data, reconciled against the retailer's own reporting, because it feeds a contractual accrual dispute where being off by a point costs real money.

Both teams built the correct metric for their job. Nobody built the layer that tells the room, or an agent, which correct answer belongs to which question.

Alation's research on this exact pattern found that unifying data language across an enterprise is roughly 70% organizational and only 30% technical — which is a direct explanation for why buying a better semantic layer product rarely closes this gap, no matter how well-engineered it is.

Once an agent answers with confidence, the disagreement moves downstream into the room.

Why this stops being survivable once an agent is asking

Ask a Slack-embedded agent "what's our sell-through on this SKU this quarter?" and it queries the semantic layer, finds an object called `sell_through_rate`, and returns one number with total confidence. No visible seam. No hint that a differently-scoped, equally valid version sits three tables over. The category manager and the finance lead never get the chance to argue about it, because the agent never knew there were two jobs to serve in the first place. It confidently found the wrong version of the right data — and handed it to whoever asked, as fact.

Six platforms, six good answers, and a wall they all hit in the same place

Every major platform in this space picked a genuine, narrow slice of the problem and solved it well. Every one of them still assumes a metric has a single correct, discoverable, executable answer once you've solved their slice.

Slice	Platform example	Question it answers	What it governs	What it leaves unresolved
Metric execution	Databricks Unity Catalog Metric Views, dbt MetricFlow	How do we compute this once and reuse it everywhere?	The formula, its dimensions, and where it can be queried	Whether the formula itself should differ by requester
Glossary governance	Microsoft Purview	What does this term mean and who owns it?	Vocabulary, stewardship, term-to-asset linkage	Convergence between competing definitions across teams
Interchange	Open Semantic Interchange (OSI)	How do we move a definition between vendors without it drifting?	Cross-tool representation of metrics, dimensions, relationships, context	Whether two valid variants of one metric should coexist by design
Graph reasoning	Neo4j semantic layer	How does an agent build the right query cheaply and accurately?	Schema and concept traversal paths for Text-to-SQL	Which of several valid paths a given decision actually requires
Certification	Tableau	Which dashboard should a business user trust?	Trust signaling, delegated governance from upstream sources	Detection of a legitimately different metric hiding under the same name
Conversational context	Dagster Compass	How do users ask questions without a modeling project first?	Learned, org-specific conversational context	Portability of that learning and modeling of why teams differ

Run the sell-through scenario through each one and the wall shows up in exactly the same place every time.

• A Databricks Metric View or dbt semantic model can encode the finance lead's promo-window formula precisely — but only if someone already built it as a separate object from the category manager's version, and nothing in either platform prompts a modeler to realize two objects were needed in the first place.

• Purview can host a glossary term for "Promotional Sell-Through Rate" with a steward attached — but nothing stops a second, differently-scoped "Sell-Through Rate" term from also existing, and the category manager finding it first.

• OSI will faithfully carry either version between tools, preserving native query logic — but has no opinion on when a second variant should be authored instead of reused.

• Neo4j's graph helps an agent build the join between the promotion table and the POS-scan table quickly — but if the agent isn't told which path is finance-approved, it traverses to whichever path is cheapest, not whichever is contractually correct.

• Tableau's certification badge tells the finance lead which dashboard is "trusted" — but if the certified dashboard happens to use the shipment-based formula because that's what got built first, certification actively reinforces the wrong number for her specific job.

• And Compass would eventually learn her team means something different through her corrections — but that learning stays locked inside her org's instance, invisible to anyone building a new agent from scratch.

Gartner is already describing this exact problem. It just hasn't named it yet. Their prescription for what comes next — a "context layer" built from knowledge engineering and decision graphs, layered above raw semantics to connect data to the decision being made — is a description of job-contextual resolution without the label attached. Gartner is telling the market it needs to know which meaning applies to which decision. It just keeps calling that "more context" instead of calling it what it is: proof that the semantic layer was never solving the full problem, only the easier half of it.

The question nobody's roadmap is actually asking

None of the six categories above were built to ask whether a metric name should resolve differently depending on who's asking and what job they're trying to get done. They ask what the right formula is, what the right term is, how to move it, how to query it cheaply, which version is trusted, how to ask for it in plain language. Not one of them asks which approved version of the truth a specific decision actually requires.

That question doesn't go away because the tooling got better. It just goes quiet — until the agent in Slack answers it wrong, with total confidence, and nobody in the room knows enough to push back. The QBR argument was survivable because two humans were in the room to have it. The next version of this failure won't come with a room.