How do you govern metric definitions so every team and BI tool reports the same number?

## Why this is a governance problem, not a tooling one Buying a semantic layer does not make numbers agree. It gives you a place to put the agreement once it exists. The failure mode in real companies is not "we had nowhere to define revenue" — it is "three people defined it, none of them was authorised to, and nobody removed the other two." So the design work is social as much as technical. ## Ownership: a name, not a team inbox Each published metric needs two owners: - A **business owner** who decides what it means. For revenue that is finance; for churn it is whoever is accountable for churn. This person resolves definitional disputes, and their authority is what makes the resolution stick. - A **modelling owner** who implements and maintains it, usually an analytics engineer. A metric with no named owner is by definition uncertified, and should be labelled that way in the catalog. The absence of an owner is itself information consumers need. ## Definitions as reviewed code Definitions belong in version control next to the models they read: text, diffable, reviewed. That gives you the ordinary software affordances — history of what the metric meant when, a review conversation attached to each change, and the ability to say precisely what changed and when a number moved. The review should include **impact analysis from lineage**: which dashboards, extracts and downstream metrics reference this definition. A change to `net_revenue` touching two hundred dashboards is a different decision from one touching two, and the reviewer cannot know which without the graph. For material changes, prefer publishing the new definition alongside the old under a distinct name, migrating consumers, then retiring the old one — rather than mutating a definition under live consumers and letting a board pack move overnight. ## Certification tiers make trust explicit Three tiers cover most needs: - **Certified** — owned, reviewed, tested, safe to use in reporting that leaves the team. - **Experimental** — someone's work in progress, visible so it can be reused and eventually promoted, explicitly not for external reporting. - **Deprecated** — still resolving but scheduled for removal, with the replacement named. The tier must be visible at the point of consumption, not buried in a wiki. A consumer choosing between two similarly-named metrics needs to see which one is certified while they are choosing. ```yaml metric: name: net_revenue status: certified business_owner: controller modelling_owner: analytics-engineering definition: sum(gross_amount - discount_amount - refund_amount) source: mart_finance.fct_order_line replaces: revenue_legacy notes: Excludes cancelled orders and internal test accounts ``` ## Make the governed path the fast path This is where most metric-governance programmes actually fail. Analysts are not adversaries; they are people with a deadline. If the certified path takes three weeks of queue and the private-SQL path takes an hour, private SQL wins every time, and no policy document changes that arithmetic. Practical levers: keep metric additions small and shippable in days, let analysts propose definitions themselves through review rather than filing tickets, and provide an explicit uncertified sandbox where exploration is legitimate and clearly labelled. Exploration is not the enemy — *unlabelled* exploration reaching a board deck is. ## Detect drift, don't just forbid it Add scheduled reconciliation: the certified metric versus the finance system of record, or two derived reports that should agree. Alert on divergence. Track adoption too — the share of dashboards built on certified metrics is a better health measure than the number of metrics defined, because it tells you whether governance is being used or bypassed. ## Accept legitimate plurality Sometimes two definitions are both correct because they answer different questions: recognised versus booked revenue, active users on a 7-day versus 30-day window. Forcing one number does not settle that; it drives the second definition into a spreadsheet where it is invisible and unversioned. Name both explicitly, publish both as certified, and document the expected relationship between them. What you are eliminating is *unnamed* plurality — two things called `revenue` — not the existence of two real business measures. ## Withdrawal is part of governance A metric nobody owns and nobody uses is a liability, because someone will eventually find it and trust it. Mark it deprecated, name the replacement, notify the consumers lineage identifies, give a notice period, then actually remove it. Governance programmes that only ever add definitions produce a catalog of thousands of metrics that is no more trustworthy than having none. ## In an interview Lead with ownership, because that is the part candidates skip. Then reviewed definitions, visible certification, and — the answer that shows you have run this rather than read about it — making the governed path faster than the workaround, and measuring adoption to find out whether you succeeded.