Here is a scene that happens in every organisation above a certain size. Two people bring numbers for the same metric to the same meeting and the numbers differ. An hour is spent finding out why. The answer is that one report excluded internal transfers and the other did not, and both were correct according to whoever built them.

That is not a data quality problem and it is not a tool problem. It is a definition-ownership problem, and it is what the semantic layer exists to solve.

In every dashboard. The default state. Each report author writes their own query or their own measure. It is fast to start, it scales to zero, and it produces the meeting described above. Every self-service estate arrives here without anyone deciding to.

In the BI tool's model. One shared, governed model that reports build on. This genuinely works, and it is the single highest-value governance move most organisations can make. Its limitation is that the definition is trapped in one vendor's model — a data scientist in a notebook, an application making an API call, or a second BI tool cannot reach it, so they reimplement it and you are back to disagreement across tools rather than within one.

In the warehouse. Definitions expressed as views or as a transformation project, so every tool that queries the warehouse sees the same numbers. This is the pragmatic majority answer and it is a good one. Its weakness is that SQL views express a fixed grain poorly — a metric that must be correct at daily, weekly and customer grain, and that involves a ratio or a distinct count, cannot simply be pre-aggregated, because those do not sum.

In a dedicated semantic layer. Metrics, dimensions, joins and grain are declared once, and consumers query the layer through an API which compiles the request into SQL. BI tools, notebooks, applications and increasingly AI agents all get the same answer, because there is only one place the answer is written.

• The BI-native model — a shared model inside the BI tool, consumed by reports built on it, and increasingly reachable over an API by other clients. The strongest option if you are genuinely single-vendor, and the weakest bet if you are not.
• The code-first modelling language approach — definitions in version control, reviewed like code, compiled to SQL at query time. Its virtue is engineering discipline: pull requests, tests, a history of who changed the definition and why. Its cost is that changing a metric requires someone who can write the model, which is exactly the friction that makes people route around it.
• The transformation-project semantic layer — metrics defined alongside the models that build the tables, queried through a server that compiles to warehouse SQL. The appeal is that it sits where the transformations already are, so the definition lives next to the data that produced it.
• The standalone universal layer — a separate service that sits between any warehouse and any consumer, usually with aggregate awareness and caching built in. Most flexible, and one more system to operate.
• The warehouse-native option — both major warehouse vendors have moved to offer semantic definitions inside the platform itself, which is a significant development because it removes the ‘another service to run’ objection entirely.

On interoperability, be sceptical of the marketing. Every one of these claims to be consumable by every BI tool. In practice the integration quality varies enormously — some connections are first-class and support drill-through and ad-hoc exploration properly, and others are a read-only bridge that returns a flat result set and loses most of the interactivity users expect. Test the specific pairing you intend to use, with a real analyst doing real work, before committing. That sentence is worth saying in an interview because it is what experience sounds like.

There is one genuinely new reason this matters more in 2026 than it did in 2022. When a person asks a natural-language question of your data, something must translate that into a query. If it translates against raw tables, it will invent joins, pick the wrong grain and produce confidently wrong numbers — and the person asking has no way to tell.

If it translates against a semantic layer, it is choosing from declared metrics with declared grain and declared joins, which is a vastly smaller and better-constrained problem. The honest framing: a semantic layer is what turns natural-language analytics from a demo into something you would let a finance team use. That is currently the strongest business case for building one, and it is a better argument than metric consistency because it is about a capability rather than about tidiness.