Every data leader has sat in the meeting where three executives quote three different numbers for "revenue" and each is right. Revenue recognised. Revenue billed. Revenue on a GAAP basis. Each is correct in its own context; none is wrong. The problem is that the three dashboards the executives are reading from each computed the definition independently, and nobody canonicalised. This is what a semantic layer is for.
What a semantic layer is, practically
A semantic layer is a versioned, tested, centrally owned definition of your metrics, dimensions and relationships, sitting between your data warehouse and every consumer (BI tools, ML features, APIs, reverse-ETL). Every consumer queries the metric layer — nobody re-implements "revenue" in a dashboard SQL query.
In 2026 the three credible options are dbt's metric layer, Cube, and Looker's LookML. All three give you versioning, lineage, testability, and — critically — the discipline that the metric is defined in one place and consumed from many.
The three problems it solves
1. The KPI disagreement problem
The one that makes the board meeting awkward. With a semantic layer, every dashboard pulling "revenue" pulls the same SQL. If the definition changes, every dashboard changes with it. If someone wants to compute a different revenue figure, they must explicitly define it — and name it — in the layer.
2. The analyst productivity problem
Without a semantic layer, every new dashboard is fifty lines of SQL that re-implements joins, filters and business rules. With it, the analyst composes metrics and dimensions. Time-to-insight drops, and — more importantly — the variance in implementation drops.
3. The consumer fragmentation problem
Modern enterprises consume metrics in BI tools, in ML features, in reverse-ETL pipelines that push back into operational systems, and increasingly in LLM-based assistants. Without a semantic layer, each consumer reinvents the metric. With it, each consumer reads from the canonical definition.
The organisational change
The technology is the smaller part. The harder part is the shift in ownership. In a semantic-layer world:
- Every metric has a named business owner, not an analytics engineer
- Metric changes go through a review with the owner and relevant consumers
- Metric definitions are published and searchable
- The metric catalogue is treated as a product — versioned, deprecated, documented
The organisations that adopt this best are those where the business is willing to own definitions. Those that struggle are ones where the BI team has implicitly owned "what the numbers mean" for years, and the business has not noticed.
Common objections
"We already have a data dictionary."
A dictionary is prose. A semantic layer is executable. The dictionary might say "revenue recognised under IFRS 15"; the semantic layer actually computes it, consistently, every time.
"It will slow us down."
For the first three metrics, yes. Slightly. After the first thirty, you are faster than before — because common joins, filters and business rules are written once. The break-even is usually month three.
"Our BI tool already has a metric layer."
Some do, at some scale. But the point of the semantic layer is that it serves all consumers, not just the BI tool. If a metric is only available inside Power BI, your ML team and your reverse-ETL team will reimplement it — and you are back where you started.
How to start
- Pick a metric that causes disagreement. Not your most important — your most contested.
- Write the definition. Get it signed by a named business owner.
- Implement it in the semantic layer of your choice. Test it against the current computation.
- Refactor one dashboard to consume it. Retire the inline calculation.
- Do the next one. And the next.
Within six months, the top fifty metrics can be under the semantic layer. Within a year, nobody is re-implementing them anywhere. This is the longest-lived investment a data team can make.