Metric Definition Layer
Business metrics defined once in a versioned, tested place and served to every consuming tool, so the number cannot differ by which tool asked.
Without it, the definition of revenue lives in a dashboard's SQL, in a spreadsheet's formula, in a notebook, and in an application query. They agree until someone changes one, and then they disagree in a way that takes days to diagnose because each is individually defensible.
A metric layer moves the definition upstream of all of them. Revenue is defined once — its aggregation, its filters, its allowed dimensions, its time grain — and every tool queries that definition rather than the underlying tables.
The properties that follow are the point. Consistency by construction. Change in one place with visible impact, because the layer knows its consumers. Testability, since a definition is code and can be asserted against known values. And governance, because certification attaches to a definition rather than to a report.
The two adoption obstacles are practical. Tools that cannot query the layer bypass it, so a metric layer with an escape hatch that half the organisation uses has not solved the problem. And migrating existing reports is unglamorous work with no visible output, which is why most implementations end up as a layer used by new reports alongside hundreds of old ones that still compute their own — the worst of both arrangements.