Semantic layer and metrics governance

Take a measure that sounds unambiguous: active customers. The board pack reports it monthly. The operations team keeps its own live view of the same measure on a screen in the office. The two numbers do not match, and they have not matched for a year.

Trace each one back and the calculation splits into three decisions. Which source table are we counting from. Which filter says what counts as active. Which time window are we counting over. The board pack counts customers who paid in the period, drawn from the billing tables, over a rolling quarter. The operations view counts anyone who signed in, drawn from the product event stream, over the same rolling quarter. Two of the three decisions match exactly. One does not, and that single difference is enough to produce two defensible answers to what looks like one question.

This is metric drift. It is the state in which one named measure has quietly acquired more than one definition, spread across the tools that calculate it. It rarely arrives through a decision. It arrives when someone building a new dashboard needs a number quickly, writes the query that seems obviously correct, and ships it. Six months later that query has become the operational definition for a whole team, and neither team knows the other exists.

Two things make drift expensive out of proportion to its cause. The first is that it consumes decision time. Meetings that should be about what to do about the number turn into meetings about the number itself, and that reconciliation cost recurs every reporting cycle rather than being paid once. The second is that it damages trust in a way that generalises. Once a leadership team has been shown two contradictory figures for the same measure, they discount every figure, including the ones that were never in dispute.

Drift also presents itself badly. It looks like a reporting bug, so it gets routed to whoever maintains the dashboards, who fixes the specific chart in front of them. That is a repair, not a resolution. The next new dashboard starts the cycle again, because nothing has changed about where the definition lives.

A semantic layer is a single place where business measures are defined once, sitting between the warehouse and everything that consumes numbers from it. A dashboard, a notebook or an agent does not write its own version of the calculation. It asks the layer for active customers, and the layer resolves that request into the one agreed piece of SQL.

It is worth being precise about what the layer centralises, because the term is used loosely. It typically holds four things. The entities and the join paths between them, so that no consumer has to remember how orders relate to customers. The dimensions that measures may legitimately be sliced by. The measures and the metrics built on top of them, each carrying its filters and its time handling. And the access rules, so that who may see which rows is decided in the same place as what the rows mean.

The arrangement where the layer has no interface of its own and serves every tool through an API is often called headless BI. The visualisation tools stay exactly where they are. What they give up is ownership of the definitions. That is what makes it possible to change reporting tool without reopening the argument about what revenue means.

Several implementations are in common use. The dbt Semantic Layer is powered by MetricFlow, which takes semantic models and metrics declared in YAML and generates the SQL for each request, working out the join path from the declarations rather than from hand-written joins. Cube is an open-source semantic layer that exposes its definitions through several standard interfaces so that any consumer can plug into them, including a Postgres-compatible SQL interface. LookML plays the same role inside Looker. They differ in packaging and in how much of the query engine they own, but they agree on the core move: the definition becomes a file that lives in version control, not a fragment of SQL living inside a chart.

None of this is a new idea in data management. It is the idea of registering the meaning of a data element once, in a managed register, so that everyone referencing that element references the same definition. That principle is standardised, and it predates every tool named above.

The layer also depends on modelling work done earlier in this course. A metric is meaningless without a stated grain, because the grain fixes what one row represents and therefore what is being counted. Dimensional models that share conformed dimensions are what let two metrics be sliced by the same region or the same period and still compare. A semantic layer laid over an incoherent warehouse does not fix the warehouse. It makes the incoherence visible in one place, which is an improvement, but it is not the same thing as a fix.

Centralising a metric inside one vendor's semantic layer removes the drift and introduces a different exposure. The definitions are now the most valuable governed asset the analytics estate has, and they are expressed in a format that one supplier controls. Migrating tools means rewriting them.

The Open Semantic Interchange is the industry response. It launched in September 2025 with Snowflake, dbt Labs and Salesforce among the initiating firms, and it has since grown into a working group with a large membership across the analytics, BI and AI vendors. It describes itself as an industry-wide specification effort to standardise how semantic metadata is exchanged across analytics, AI and BI platforms, giving a vendor-neutral single source of truth for semantic data. The specification is published under an Apache 2.0 open-source licence.

Be precise about what it standardises, because this is where descriptions of it tend to overreach. It standardises the exchange format for semantic metadata: metrics, dimensions and the joins between entities, expressed declaratively in YAML. It does not standardise how any engine computes a result, it does not prescribe a warehouse, and it does not tell an organisation what its metrics should be. The claim is portability of meaning, summarised by the initiative as writing a definition once and querying it anywhere.

Treat it as an initiative rather than as a settled fact of the landscape. A specification with vendor backing is a promise about interoperability; the thing that makes it real is whether the tools an organisation actually runs read and write it faithfully. Until that is demonstrable, the practical stance is to ask each supplier what its support amounts to and to keep metric definitions in version control in a declarative form, which is worth doing on its own terms and leaves the door open if the standard holds.

Until recently every consumer of a metric was a person. A person who has worked in the business for two years looks at a customer count that is ten per cent higher than last week and stops. That instinct is an unpaid quality control that the whole reporting estate has been quietly relying on.

Agent access removes it. Once an assistant can reach a warehouse through a standard connector such as the Model Context Protocol, it can enumerate tables, read column names and write SQL. What it cannot do is know which of the four plausible definitions of active customer the organisation treats as authoritative, because that decision is not recorded anywhere the agent can read. It will pick one, write correct SQL against it, and return an answer with no hedging at all.

That failure mode is worse than a human error in three ways. It is confident, so nothing in the output signals that a judgement was made. It is unrepeatable, so the same question asked twice can resolve to different definitions. And it scales, because an agent asked forty questions makes forty of these silent choices in the time a person makes one.

A semantic layer is the correction, because it turns the missing judgement into a lookup. The agent does not choose a definition; it requests a named metric and the layer resolves it. The same layer is also the sensible place to enforce which rows the agent may see, since access rules and meaning then change together rather than in two systems that drift apart. This is why an argument about dashboards that was tolerable for a decade became urgent within about a year of agents getting query access.

A usable metric definition is short. It is not a document and it is not a modelling exercise. It is five fields that someone has actually decided:

1. Name. The exact label that will appear on every chart. If two teams need genuinely different measures, they get two names, not one name and a footnote.
2. Grain. What one counted thing is. One customer, one order line, one meter reading in one half hour. Stated before any column is chosen.
3. Filters. Every condition applied, including the ones that feel too obvious to write down, such as excluding internal test accounts or cancelled orders. Unwritten filters are where drift starts.
4. Source. The specific table or model the measure is built from, so that a reader can go and look.
5. Owner. A named person who decides when the definition changes. Not a team, not a committee.

Two fields are worth adding as soon as the first argument recurs. A time window, stating whether the measure is a point-in-time count, a rolling period or a calendar period, since a surprising share of disagreements are only about this. And the set of dimensions the metric may legitimately be sliced by, which stops a measure defined at one grain being broken down by something that produces double counting.

Written out, the earlier example becomes a definition rather than an assumption. Active customers: a count of distinct customers, where the customer has at least one successful payment in the period, excluding internal and test accounts, built from the billing model, measured over a rolling ninety days, sliceable by region and plan, owned by the finance data lead. Anyone can now disagree with that. What they can no longer do is disagree with it accidentally.

Ownership only means something if a change to the definition is a change to a file. When the definition lives in version control, altering it produces a reviewable difference, a date and an author, and the dashboards that move as a result move because someone approved it. That is also the point at which a metric can carry tests, the same way a data contract carries expectations about the dataset underneath it, so that a change which would silently break a downstream figure fails in the build instead of in the board pack.

Finally, connect the definition to the language around it. The entry in the business glossary explains the term to someone who does not write SQL; the metric definition is what runs. Where the two reference each other, a reader who starts from either end reaches the same answer, and the organisation stops maintaining two competing accounts of what its own words mean.

Metrics governance fails in two opposite directions, and it is worth naming both because organisations tend to overcorrect from one into the other. The first is the free-for-all already described, where anyone can define anything and nothing is authoritative. The second is a central committee that must approve every new measure, which produces a queue, and a queue produces exactly the same shadow definitions the committee was created to prevent, only now they are hidden.

The arrangement that survives contact with a real organisation sits between the two. A small set of measures is treated as certified: the ones that appear in board reporting, in regulatory returns, in incentives and in anything published outside the organisation. Those have named owners, review dates and tests, and changing one is a deliberate act. Everything else is left open, clearly marked as uncertified, and allowed to evolve wherever the analysis needs it. Analysts get their speed, the numbers that carry consequences get their control, and the boundary between the two is visible in the tooling rather than in a policy nobody reads.

Two operational habits do most of the work. The first is treating a definition change as a release. When the finance lead decides that refunds should be netted off revenue, that decision has a date, an author and a note explaining why, and it is possible afterwards to say which figures were produced under which definition. Restating history without a record is how organisations lose the ability to explain their own trends. The second is retiring measures. A metric catalogue that only ever grows becomes unusable at a few hundred entries, and a measure nobody has queried in a year is a liability rather than an asset, because someone will eventually find it and treat it as authoritative.

Adoption is the part that is usually underestimated. A semantic layer that half the estate bypasses has not removed drift; it has added a fourth definition alongside the three that already existed. The honest measure of success is not how many metrics have been defined but what share of the numbers that reach a decision-maker were resolved through the layer. That figure is knowable, because the layer logs every request, and it is the one worth reporting to whoever sponsored the work.