For ten years, enterprise data architecture has been organized around the technical project of making data accessible. Storage and compute decoupled. Open table formats matured. Federated query engines learned to read across warehouses, lakehouses, and operational systems through a single SELECT. Much of the architecture imagined in 2018 has now been built. And yet the average enterprise still loses millions a year to duplicated definitions and metrics that mean different things in different rooms — because the hard problem was never merely getting to the data. Access is not the same as meaning.
The next data-platform fight is not over who can reach the most data. It is over who gets to define what that data means.
Querying is not easy in the trivial sense. Distributed execution, predicate pushdown, identity propagation, and cross-source joins remain serious engineering problems. But they are problems with machinery. Meaning is a problem with institutions. The chart below makes that distinction visible: two text-to-SQL benchmarks, both translating natural language into SQL, with one running on clean academic schemas and the other on real enterprise complexity (3,000+ column schemas, multiple SQL dialects, multi-step workflows, project-level codebase navigation).
These are not apples-to-apples benchmark scores. Different evaluation harnesses, model classes, and prompting regimes produce different results. The chart is a directional illustration of what happens when text-to-SQL moves from clean schemas to enterprise-like workflows — not a controlled comparison.
The dominant architecture has converged on five layers: object storage, table format, catalog, query engine, consumer. More engines can now query more tables through shared formats and catalogs than at any previous point in the data stack. The technical achievement is real, widespread, and worth naming before pointing to what it didn't solve. Hover any tool for context.
Consider "monthly recurring revenue" in any enterprise that has done at least one reorg. MRR exists in all six layers simultaneously, each version a legitimate engineering decision, none authoritative over the others. Below: the six layers, then where teams are actually putting their semantic enforcement.
Source · Reliable Data Engineering survey (n=500+) · Dec 2024–Jan 2026 · community/industry analysis · multi-select, totals exceed 100%. Treat as directional rather than market-representative.
The semantic layer was a nice-to-have when humans wrote queries. It is load-bearing infrastructure when agents do.§ 04 · The Five Bets · May 2026
If business definitions are the substance of institutional truth, the layer where they are enforced is one of the most consequential pieces of infrastructure an enterprise owns. The contest is currently split across five architectural schools. Each card shows the bet, the canonical implementation, and the limit.
Metrics defined in YAML alongside dbt models, version-controlled in Git, exposed via APIs to downstream tools. The bet: definitions belong with the transformations that compute them. The limit: dbt cannot enforce what BI tools do downstream — and the LLM never reads the manifest unless you integrate it.
# metrics.yml metrics: - name: monthly_recurring_revenue label: "MRR" type: simple type_params: measure: mrr_cents filter: | {{ Dimension('contract__status') }} = 'active'
Put the definitions inside the warehouse and let every engine that queries it honor them. Snowflake Semantic Views moved into GA-era productization in 2025; Databricks Unity Catalog metric views entered public preview in 2025 and continued maturing through 2026. The bet: the warehouse is already where the data is. The limit: 38% of organizations run multiple warehouses — semantics in any single one are still siloed across the federation.
CREATE SEMANTIC VIEW analytics.mrr_view TABLES (contracts, invoices) RELATIONSHIPS (contract_id) FACTS ( mrr AS SUM(invoices.amount_cents)/100 ) DIMENSIONS (status, segment, region);
In a federated architecture, the only layer that natively reads across all warehouses, lakes, and operational systems is the query engine itself. The bet: cross-source consistency requires a cross-source enforcement point. The risk: this is powerful, but it also makes the federation layer politically dangerous — it becomes a governance surface, not just a query surface. Platform engineering inherits business-definition governance whether it wants that role or not, and most platform teams are neither staffed nor mandated to make calls about whether a contract counts as active.
CREATE VIEW federation.mrr AS SELECT date_trunc('month', i.date) month, SUM(i.amount_cents)/100 AS mrr FROM postgres.billing.invoices i JOIN iceberg.crm.contracts c ON i.contract_id = c.id WHERE c.status = 'active';
A separate runtime with caching and pre-aggregation. The bet: warehouse-native gives up performance optimizations; a dedicated layer can serve any downstream tool uniformly. The limit: yet another runtime to deploy, scale, and govern. Per-tool semantics if each BI vendor maintains its own.
cube('MRR', { sql: `SELECT * FROM analytics.contracts`, measures: { mrr: { type: 'sum', sql: 'amount_cents/100' } } });
Each consuming product builds its own semantic store — quietly, often unacknowledged. The bet: definitions are most relevant at the point of use. The risk: re-fragmentation, this time per-agent or per-vendor. The fastest-growing category and the worst architectural outcome — it re-creates the problem the federation layer was built to avoid.
# LLM Assistant · system prompt You are an analytics assistant. When users ask about revenue, query the 'invoices' table and sum the 'amount' column. Exclude refunds. ↑ drifted from canonical MRR in 3 ways
The Open Semantic Interchange (dbt + Snowflake + Salesforce, 2025) is the direct semantic-interchange bet: a shared format for metric definitions across vendor boundaries. MCP (Anthropic, ecosystem-wide) is the adjacent interface bet — if agents consume tools and resources through standardized protocols, semantic definitions need to become addressable through those protocols. The two are complementary, not equivalent. Whether either holds, or each major vendor consolidates ownership inside its own platform, is the structural question of the next three years.
# MCP semantic layer interface { "server": "metrics.acme.com", "capabilities": ["resources", "tools"], "metrics": [{ "name": "mrr", "definition": "canonical", "source": "dbt_semantic_layer" }] }
The hardest semantic-layer decision is not where definitions are stored, but who is allowed to change them. A metric definition without an owner is documentation. A metric definition with an owner, review process, lineage, tests, and release cadence is infrastructure. The architectural layer matters because it determines the enforcement point; the operating model matters because it determines whether enforcement survives contact with the business.
Three things data architects, platform leads, and consultants should internalize from the current state of the contest.
The decision is not dbt vs Snowflake vs Trino vs Cube. It is: which team owns the definition of revenue, and at which layer of the stack is that definition enforced? S3 (transformation) optimizes for upstream truth. S4 (engine) optimizes for cross-source consistency. S5 (BI) optimizes for end-user fidelity. Each has a tradeoff. The wrong answer — held by 35% of teams — is all of the above, by accident.
A definition stored at S3 and consumed at S6 crosses three potential rewriting points. Each hop is a place where local context overwrites the upstream definition for good local reasons. The architectural work is not to document each layer's exceptions — it is to shorten the path. Trino's value as a federation layer is that it can expose cross-source definitions through one enforceable access point. That value is only realized if downstream BI tools and consumers honor the engine-level view rather than silently recomputing.
A human analyst asking "what's our revenue" can detect a wrong answer because they have surrounding context. A language model has only what was injected. By the time Gartner's 33% agentic AI projection hits in 2028 — a 36-month timeline — every semantic ambiguity in the stack becomes a confidence-weighted production bug. The migration is not from BI tools to LLMs. It is from triangulating consumers to non-triangulating ones. Design for the latter.