Data Products Are Dead, Long Live Semantic Products

The Promise, and the Crack in It

For a few years, "data products" felt like the breakthrough the industry had been waiting for. Data teams were stretched thin, dashboards were multiplying, metrics contradicted each other, and ownership was unclear. So we borrowed an idea from software engineering: treat data like a product. Give it an owner. Define a contract. Document it. Version it. Ship it.

It worked — for what it was designed to do. From 2021 to 2024, decentralization fixed a real bottleneck. Domain teams stopped queuing behind a central data team. Time-to-market for new datasets collapsed from quarters to weeks. Ownership became legible. Uber, Netflix, Airbnb, and LinkedIn all built sophisticated internal platforms on these principles, and thousands of enterprises followed.

But there is a quiet assumption buried inside the data-product movement: if data is packaged cleanly and documented well, consumers will use it correctly. That assumption held when questions were predictable, consumers were trained analysts, and definitions changed slowly. It breaks down in a world where data is consumed by humans, dashboards, alerts, and AI agents simultaneously — where context varies by role, by moment, and by intent.

The result is not misuse of data. It is misalignment of meaning. Data products have arrived, but meaning still drifts. Teams own datasets; they don't own definitions. "Revenue" means one thing to Finance and another to Sales. "Active user" varies between the business team and the analytics team. And the three forces reshaping enterprise data in 2026 — autonomous AI agents, multi-source data estates, and regulatory explainability mandates — are precisely the forces that the data-mesh model was never built to withstand.

The Governance Problem Data Mesh Left at the Edges

Data mesh's fourth principle — federated governance — was supposed to handle semantic consistency. The assumption was that domains could govern locally and that consistency would emerge naturally from shared standards. In practice, it often doesn't.

Data products specify a contract: schema, freshness, availability, SLOs. What no data-product contract specifies is meaning. A contract tells you the revenue column will be populated by 6 a.m. with 99.9% availability. It does not tell you whether revenue is gross or net, whether it excludes refunds, which currency-conversion date it uses, or whether trial users count as "active." Two perfectly compliant data products can encode contradictory meanings. Three failure modes recur:

• The semantic-alignment problem. Teams own data products but define terms differently. Search a mature catalog for "revenue" and get hundreds of results, many outdated, some contradictory. The mesh stops working.
• The governance-sprawl problem. Without robust federated governance, each domain picks its own tools, formats, naming conventions, and quality thresholds. Decentralization optimizes for local speed but fragments global consistency.
• The shadow-product problem. When teams don't trust the "official" data product, they build parallel datasets. Inconsistent metric definitions often lead teams to create their own dashboards to "fix" the data, breeding confusion and mistrust.

This is the "reconciliation tax." Every quarter, teams spend meaningful time aligning metrics across domains before anyone can trust a number. The cost is real and now measurable. Gartner research from 2020 found poor data quality "costs organizations at least $12.9 million a year on average," with "inconsistency in data across sources" as the most challenging data-quality problem — the result of having data stored and maintained in silos with significant overlaps, gaps or inconsistencies. dbt Labs' 2024 State of Analytics Engineering found poor data quality "emerging as a predominant issue for 57% of professionals," with data scientists spending roughly 45% of their time "getting data ready (loading and cleansing) before they can use it."

This is what we call semantic debt — the technical-debt cousin of knowledge drift. Unlike broken pipelines, semantic decay doesn't announce itself. The data is accurate, the pipelines are correct, the schemas are valid — but the system slowly stops telling the same story it once did. Technical debt slows systems down. Semantic debt makes systems untrustworthy. Unlike other forms of accidental complexity, semantic debt lives in assumptions, not code, making it invisible until it breaks something.

Why AI Broke the Data-Mesh Model

Data mesh works for human analysts asking known questions of data products they understand. A trained analyst who hits an ambiguous revenue column knows to ask, to investigate, to apply contextual judgment. But autonomous AI agents reason over the implicit join relationships encoded in data-product contracts — relationships that contracts specify structurally but not semantically. When the relationship isn't explicit, the agent invents one.

A documented enterprise case: agents "generated queries referencing columns that sounded reasonable but didn't exist, hallucinating a 'customer_segment' field that actually required joining to a separate dimension table." When the organization supplied explicit semantic definitions — what "revenue" means, how "customer segment" is derived, where it lives — "query generation accuracy improved from approximately 30% to approximately 75%."

The pattern is consistent across the industry. Raw text-to-SQL accuracy "nearly doubled, from 32.7% to 64.5%," but "for questions within the Semantic Layer's scope, both models now return correct results 100% of the time." Snowflake reports its semantic model boosts text-to-SQL accuracy "by 20% (on average)" over LLMs alone. The BEAVER enterprise benchmark — schemas averaging 105 tables and 4.25 joins per query — finds state-of-the-art models "fail on both table retrieval and SQL assembly even when given full schema access." This is not a model-capability problem; it is a context-infrastructure problem. And the stakes scale: an agent that produces a revenue number 8% too high because it didn't know about the refund-exclusion rule, and that number reaches a board deck, is a materially different class of failure than a chatbot mistake.

Federated governance cannot enforce deterministic reasoning, because it governs delivery at the domain edge, not meaning at the point of use. That is the structural reason AI broke the data-mesh model.

Introducing Semantic Products

A semantic product is not a rejection of data mesh. It is a layer above it. Where a data product answers "what is available," a semantic product answers "what it means." Data products focus on delivery; semantic products focus on comprehension.

Concretely, a semantic product differs from a data product on four axes:

1. Meaning is first-class, not an afterthought. Entities, metrics, relationships, constraints, and policy are modeled explicitly, not left implicit in column names and wiki pages.
2. Relationships are typed, not implied. A join path between Customer and Subscription is declared and provable, not inferred at query time by a human or guessed by an agent.
3. Context is explicit, not inferred. The definition of "active user," the refund-exclusion rule, the currency-conversion date — all travel with the metric.
4. Evolution is managed, not chaotic. As schemas and definitions change, autonomous agents detect drift and propose updates, rather than letting meaning decay silently.

The properties that follow are the ones data mesh couldn't guarantee: autonomous maintenance (the graph keeps pace with schema changes), cross-domain consistency (enforced at compile time, not reconciliation time), AI-readiness (agents reason over explicit semantics rather than probabilistic guesses), and auditability (every answer carries lineage from intent to SQL to source). Autonomous semantic systems replace manual definitions, documentation, and knowledge drift with continuous intelligence. From metric stores to knowledge machines — that is the trajectory of what replaces static metric definitions.

This is a "meaning as infrastructure" shift. Just as data mesh did for data ownership — making it a first-class, owned, productized thing — semantic products do for meaning governance.

The Semantic-Products Landscape

There is no single winner. "Semantic layer" now means at least four different products, and the right one depends on your data estate and governance appetite.

• Colrows positions itself as a semantic execution layer: a runtime that compiles agent or human intent into "governed, deterministic, dialect-perfect SQL," with every join proven at compile time and RBAC/ABAC/row- and column-level policy enforced before any SQL touches the warehouse. Its differentiators are an autonomous semantic graph (built and maintained by AI agents, seeded from warehouses and catalogs), cross-warehouse reach (16+ engines including Snowflake, Databricks, BigQuery, Redshift, Postgres, ClickHouse, Trino), and meaning-first, deterministic compilation. It is built for AI-agent execution, not primarily for human dashboards.
• dbt Semantic Layer / MetricFlow treats metrics as code: semantic models and metrics defined in YAML, versioned in Git, with MetricFlow generating optimized SQL and performing dynamic joins at query time. Its strength is metrics-as-code discipline and the broad dbt ecosystem; the trade-off is that the semantic graph is hand-authored in YAML rather than autonomously built, and it is metric/BI-centric rather than agent-execution-centric.
• Cube is a headless universal semantic layer: one metric definition exposed through SQL, REST, GraphQL, and MDX APIs, open-source core, used heavily for embedded and customer-facing analytics.
• Atlan is explicit that it is a context layer, not a semantic layer per se: it ingests semantic definitions from dbt, Cube, AtScale and wraps them with ownership, lineage, quality, and policy, exposing the result to agents. It is governance-and-context-first, designed to sit alongside a semantic engine rather than replace it.
• Collibra and Alation are governance-first catalogs moving toward semantics, with launched semantic agents and deepened integrations. Both still rely heavily on manual curation.

The data-modeling paradigms — from Kimball dimensional models to dbt analytics engineering — all solved real problems but are now incomplete. Semantic products represent the next evolution.

From Data Mesh to Semantic Products — The Migration Path

The single most important thing to tell an anxious leader: this is an overlay, not a rip-and-replace. Data products don't disappear; they become the substrate that feeds semantic products. Domain teams keep owning their data products. A central team owns the semantic layer that sits above them.

A pragmatic rollout looks like this:

• Weeks 1–2: Connect a connector and auto-build an initial semantic graph. Pick 3–5 high-value data products to model first.
• Weeks 2–6: Model your highest-friction cross-domain metric — revenue, churn, or a compliance metric — semantically, while data mesh keeps running underneath. Validate that the semantic definition reconciles against existing canonical numbers.
• Production rollout: In regulated environments (SSO, policy authoring, validation against existing definitions), "production rollouts typically run in weeks, not months, depending on environment complexity."

Risk is minimal because nothing is being removed; you are adding a meaning layer above an existing delivery layer. Success metrics to track: reduction in reconciliation cycles, faster time-to-new-insight, and increased AI-agent accuracy on cross-domain questions.

The Decision Framework

Stick with data mesh (alone) when:

• You have a single primary warehouse and your analytical surface lives inside it.
• Definitions are relatively stable and change slowly.
• You have a mature, federated governance culture already functioning.
• Your AI/agent roadmap is not urgent, and consumers are mostly trained human analysts in one BI tool.

Layer semantic products on top when any of these are true:

• Multi-source reality: your data spans Snowflake + Databricks + BigQuery (or operational DBs). Warehouse-native surfaces stop at the warehouse boundary.
• AI/agent roadmap: you are putting agents into production and pilots are stalling on semantic alignment.
• Rapid metric evolution: definitions change faster than documentation can keep up.
• Cross-domain consistency requirements: the same concept must mean the same thing across domains, enforced at compile time.
• Regulatory compliance: the EU AI Act's high-risk obligations require auditable data lineage, technical documentation, and step-by-step explainability.

Suggested thresholds that should trigger evaluation: more than ~30% of analyst time spent on reconciliation; two or more systems of record; AI-agent pilots failing on join/definition errors; or any high-risk EU AI Act system needing on-demand explainability before August 2, 2026.

The Next Chapter

Data mesh decentralized data ownership. Semantic products decentralize ownership while centralizing meaning — domains keep their autonomy, but the enterprise gets one consistent, governed, executable definition of what things mean. The hardest problem in enterprise systems is not scaling data. It is scaling agreement.

This shift is less a choice than a trajectory. As AI agents move into production and compliance pressure intensifies through 2026, the cost of forgotten meaning compounds — exponentially, not linearly. Organizations that move early get consistency without losing speed; the ones that wait inherit growing semantic debt, conflicting logic, and stalled AI initiatives.

So the real question for a data or product leader is not "data mesh or semantic products?" It is "when do we layer semantic products on top of the data mesh we already built?" For most enterprises facing multi-source data, an AI roadmap, or a 2026 regulatory deadline, the honest answer is: now.