Metric governance

A metrics file without governance is just a new place to have the old argument. What makes the layer authoritative is process — light enough that people use it, firm enough that 'I changed revenue's definition in a hotfix on Friday' cannot happen. Four mechanisms carry all of it:

• Ownership. Every metric names one accountable owner — a person or team, not 'data'. The owner arbitrates edge cases, approves changes, and answers 'why did this move?' No owner, no certification. This mirrors the model-inventory discipline from the AI Governance course: artifacts that matter get named humans.
• Certification tiers. certified: true means: definition signed by the owner, tested, safe for exec reporting and AI-agent consumption. Uncertified metrics are visible but flagged — usable for exploration, quotable by nobody. Two tiers is enough; five tiers is a bureaucracy generator.
• Change control. Definitions live in git; changes arrive as pull requests; the owner reviews; the merge is the approval, and the diff is the audit trail. Changing net_revenue should feel roughly as weighty as changing the payroll calculation — because downstream, it is.
• Versioning & deprecation. When a definition must change materially (finance moves refund recognition to refund-month), you don't silently edit — you version (net_revenue_v2), run both during a transition window, annotate dashboards, then retire v1 on a date. Every consumer gets continuity; nobody gets ambushed by a chart discontinuity they can't explain.

Governance is what makes AI consumption safe

Here's the loop that makes this module matter beyond dashboards: an analytics agent should be restricted to certified metrics for authoritative answers. Then the blast radius of a wrong AI answer is bounded by your certification process — a process with named owners and reviewed diffs — rather than by an LLM's improvisation. Governance turns 'can we trust the AI's numbers?' into 'do we trust our own definitions?', which is a question a company can actually answer.