From Ledgers to Intelligence Part 14: The Semantic Layer One Definition to Rule Them All

Digital Transformation | June 2026

By 2021, most organisations with a mature data stack had accumulated a metric consistency problem of significant severity. The self-service analytics era had given every team the ability to define and publish metrics; the natural result was that every team had defined and published slightly different metrics for the same business concepts. Revenue was calculated differently by finance, by sales operations, and by product analytics. Customer count meant different things in the CRM, in the data warehouse, and in the product database. The “active users” figure used by the CEO in the board meeting was not the same “active users” tracked by the product team on their growth dashboard.

The semantic layer the idea of defining metrics once and serving them consistently to all consumers was not a new concept. Enterprise BI platforms had implemented semantic layers (Business Objects universes, Cognos Framework Manager models) for twenty years. What was new in 2021 was the combination of: a code-based approach to metric definition (stored in version-controlled YAML, not locked in a proprietary UI), a modular architecture that sat independently of any particular BI tool, and the recognition that the semantic layer was not a feature of a BI platform but a standalone infrastructure component.

The Metric Inconsistency Problem, Quantified

A survey by Benn Stancil (co-founder of Mode Analytics) in 2021 found that metric inconsistency was the most commonly cited data quality problem in analytics teams, cited more frequently than missing data, late data, or incorrect data. The root cause was structural: in a modern data stack where multiple analysts could build dbt models and multiple teams could build Tableau or Power BI dashboards, there was no mechanism preventing different teams from implementing the same metric differently.

Consider “monthly recurring revenue” (MRR) a metric that appears simple but conceals a dozen definitional choices. Should trial subscriptions be included? Subscriptions in a grace period after cancellation? Currency conversions based on today’s rate or the rate at time of charge? Revenue recognised on the invoice date, the payment date, or the subscription start date? Each choice produces a different number. In an organisation with ten analysts and no metric governance, there might be ten different implementations of MRR, each “correct” by its own implicit definition, and no easy way to identify which was being used where.

dbt Semantic Layer and MetricFlow

dbt Labs addressed this problem with the dbt Semantic Layer, built on the open-source MetricFlow framework (acquired from Transform Data in 2022). MetricFlow introduced a YAML-based metric definition language that specified not just the SQL for a metric but its semantic properties: what dimensions it could be sliced by, how it should be filtered, whether it was a simple aggregation or a ratio, and how it related to other metrics.

Once defined in MetricFlow, this metric could be queried by any connected BI tool through a standardised API with MetricFlow generating the appropriate SQL for the target data warehouse automatically. A change to the metric definition propagated automatically to all consumers. There was no longer a way to build an “unofficial” MRR figure that bypassed the MetricFlow definition the definition was the only path to the metric.

Cube.dev and AtScale: Headless BI

Cube.dev (formerly Cube.js), founded in 2019, offered a semantic and caching layer as a standalone API service the concept of “headless BI.” Rather than being embedded in a specific BI tool, Cube’s semantic layer sat between the data warehouse and any downstream consumer: Tableau could query it, Power BI could query it, a custom React application could query it, a REST API integration could query it, and an LLM agent could query it all using the same metric definitions, all receiving consistent results.

The “headless” framing was significant: it acknowledged that the BI tool was not the appropriate place to define business logic. BI tools are consumption surfaces; semantic definitions are infrastructure. Separating these concerns putting metric logic in the semantic layer rather than in BI-tool-specific calculations allowed metric definitions to survive BI tool migrations, to be queried programmatically by non-BI consumers (ML models, APIs, AI agents), and to be governed centrally without requiring BI tool expertise.

Enabling AI: The Semantic Layer as a Safety Net

The semantic layer took on additional importance with the emergence of LLM-based analytics tools (described in Part 16). Text-to-SQL systems which allow users to ask questions in natural language and receive SQL-generated answers are prone to generating technically correct but semantically wrong queries: SQL that executes without errors but applies the wrong filters, uses the wrong grain, or ignores business rules that should constrain the result.

A semantic layer provides a structured, machine-readable description of the data model: which metrics exist, how they are calculated, what dimensions they support, and what filters should be applied. An LLM generating a query against a semantic layer API cannot accidentally omit the “active subscriptions only” filter from an MRR calculation, because the filter is encoded in the metric definition not left to the LLM’s interpretation of the question. The semantic layer constrains the LLM’s output to semantically valid queries.

---

References

1. dbt Labs (2022). Introducing the dbt Semantic Layer. dbt Labs Blog.
2. Stancil, B. (2021). The missing piece of the modern data stack. Benn Stancil Substack.
3. Cube Dev (2020). Headless BI: The Future of Analytics APIs. Cube.dev Blog.
4. AtScale (2019). Universal Semantic Layer for Multi-Cloud Analytics. AtScale Whitepaper.
5. Lightdash (2022). Open-source BI built on top of dbt metrics. Lightdash Documentation.
6. Transform Data (2021). MetricFlow: A framework for defining and querying metrics.
7. Kimball, R. & Ross, M. (2013). The Data Warehouse Toolkit, 3rd ed. Wiley.