Tooling
Semantic layers, a reality check
Define the metric once, serve it everywhere. The promise is right, the adoption math is harder, and the graveyard has a pattern worth reading.
By The editors · · 3 min
The pitch has not changed in five years: revenue is defined once, in code, and every dashboard, notebook and AI assistant gets the same number. The pitch is correct. Companies genuinely do run three incompatible definitions of "active customer" across four tools, and the quarterly meeting where they collide is a real expense.

So why is the semantic layer still a minority practice? Because the pitch prices the benefit and not the toll. Every BI tool, every notebook, every consumer has to route queries through the layer, or the single source of truth becomes one more source. Partial adoption is quiet failure: the governed metric and the ungoverned copy drift, and trust, once split, does not recombine.
the graveyard has a pattern
Failed rollouts share a shape: a platform team defines two hundred metrics in a quarter, then discovers the analysts kept writing SQL because the layer could not express the weird cohort logic that makes analysis analysis. Successful rollouts share a shape too: five metrics that appear in board reporting, wired into the two tools where those numbers get read, expanded only when someone asks.
The new pressure is AI. A model answering "what was churn in March" will confidently aggregate the wrong table without a governed definition to consult, which makes the semantic layer less a BI convenience and more the difference between an assistant and a liability.
the toll, itemized
Since the pitch will not price the toll, we will. First, expressive range: cohort logic, window comparisons and the analyst's beloved "same store sales but exclude the weird week" translate into layer definitions slowly or not at all, and every metric the layer cannot express is a reason to bypass it. Second, the query path: each BI tool speaks to the layer through a connector of varying maturity, and the failure mode is not an error but a silent fallback to direct SQL, which is drift with extra steps. Third, ownership: metric definitions change, someone must review the change, and the review queue becomes a bottleneck exactly when the business is renegotiating what "active" means, which is to say at the worst possible time. None of these costs is fatal. All of them are recurring, and a rollout plan that budgets only the definition-writing quarter has priced a wedding and not a marriage.
a scorecard before you commit
Four questions, answered with numbers, tell you whether the layer pays. How many metric disputes reached an executive last quarter (the benefit, priced). How many tools would need to route through the layer for the top five metrics (the integration toll). How many people are empowered to approve a definition change (the bottleneck forecast). And what fraction of last month's analytical queries could the layer have expressed at all (the bypass rate, and the number vendors least enjoy discussing). Teams that run this scorecard tend to arrive at the narrow adoption the graveyard recommends, which suggests the graveyard was trying to tell everyone something all along.
verdict
Wait, if your metric disputes are rare and your tools are few. Adopt narrowly, if the board numbers already have three definitions: start with those numbers and those tools, and let coverage follow trust rather than precede it. The maximal rollout remains a way to spend a year discovering which of your metrics nobody agreed on.