Two teams compute "active user" differently and both numbers appear in board reporting. Which governance mechanisms address this, and which would not?

What is being tested

Whether you can distinguish governance mechanisms that change behaviour from those that merely document intentions.

What actually addresses it

A certified metric definition with a named owner. One definition of "active user", stating the window, the qualifying actions, the exclusions (internal accounts, bots, test tenants) and the timezone. Owned by a person who is accountable for it, not by a committee.

A semantic layer that implements it. The definition exists as versioned, tested code that every dashboard and query consumes. This is the mechanism that makes the definition binding rather than advisory — if the only way to get the number is to call the shared definition, divergence becomes impossible rather than discouraged.

Lineage. So that when two numbers differ, the question "where did each come from" has a mechanical answer in minutes rather than a two-day investigation.

A certified versus exploratory distinction. Analysts must be free to compute things their own way; the failure is when an exploratory number reaches a board report without anyone noticing it was not the certified one. Labelling datasets and dashboards by tier addresses exactly this, and it addresses it without slowing anyone down.

What would not address it

A catalogue with descriptions. Necessary but not sufficient. A catalogue that documents both definitions has documented the problem. Unless the definition is executed from one place, people will keep writing their own SQL — usually because it is faster than finding the catalogue entry.

A review board approving new metrics. Adds friction proportional to volume and produces workarounds rather than compliance. Teams under deadline pressure will compute what they need locally and the shadow pipeline will be invisible.

Renaming one of them. Treats the symptom. Two metrics with different names and no stated relationship is still two numbers in a board pack.

The general principle

Governance metadata must be enforced at runtime, not documented. This is the distinction that separates governance that survives an audit from governance that describes intentions. Operating a large multi-tenant enterprise platform makes this unavoidable: residency must be a placement rule the system cannot violate, retention must be a deletion job that actually runs, and access must be a policy evaluated on every request. A model that lives in a spreadsheet describes what was meant; one that lives in the request path describes what happens.

The organisational half

Someone must be accountable for the number. Not a distribution list — a person. Unowned datasets and undefined metrics degrade silently, and no amount of tooling substitutes for someone whose job it is to notice.

And note the failure mode at the other extreme: heavy governance produces shadow pipelines built to avoid it. The target is the lightest mechanism that makes the right thing easier than the wrong thing.