Most model governance is a document that is accurate on the day it is written and quietly stops being true as the code moves on. The alternative is to compile governance into the build: express each rule as something a program checks, and make a violation fail loudly, the same way a failing test does. In this programme governance is code, carried by a central registry and a set of gates that can refuse to let a model run or deploy.
The failure mode governance is meant to prevent
Most model governance lives in prose. It describes tiers, sign-offs, and fairness commitments, and it is accurate the day it is written. Then a metric gets renamed, a dependency gets assumed, a model that was supposed to wait for an upstream validation ships anyway because the person who knew about the dependency was away. Nothing enforced the policy, so the policy quietly stopped being true. Governance that lives only in prose degrades into governance theatre.
The alternative is ML governance as code: each rule becomes a condition a program checks, and a violation fails the build loudly rather than being noticed months later, if at all. Three ideas carry it, and together they turn claims into checkable facts.
Tiers, cards, and a registry that cannot be contradicted
Every model is assigned a governance tier by risk, from low-stakes internal forecasts up to legally sensitive decisions such as personalised pricing, and each carries a model card describing its method, its primary metric, its dependencies, and its approvals. Crucially, the tier and metric are not free text in the card; they are declared in a central registry that is the single source of truth.
A per-module validator fails the build if a module's manifest drifts from what the registry says. You cannot silently downgrade a model's tier or swap its metric, because the validator catches the disagreement. The registry is not documentation about the system; it is the contract the system is checked against.
Three gates that refuse to wave a model through
The first enforced gate protects the pricing optimisers from an untrusted elasticity. Optimisation is only meaningful on a validated causal estimate, so the gate reads go only once the elasticity work has passed its checks. The downstream optimiser modules read that gate at run time and refuse to run until it does. The dependency is a condition in the code path, not a note in a README.
The second is a legal gate. Personalised pricing is the highest-tier decision in the programme, and it cannot deploy without a recorded legal go or no-go: a durable artefact recording who approved, under what conditions, and on what evidence, rather than a hallway conversation. If the artefact says no-go, or does not exist, the model does not ship.
The third is a fairness circuit-breaker, and it is the one that makes the others more than paperwork. Even with a legal go, deployment halts automatically if the model fails an automated fairness test, the four-fifths disparate-impact rule. Legal approval and fairness are independent conditions, and both must hold; a model cleared one week that drifts into biased behaviour is stopped by the breaker rather than waved through on the strength of the earlier sign-off.
Enforced, not advisory
None of this depends on anyone remembering to look. A continuous-integration aggregator runs every module's validator, every test suite, and the monitoring sweep in one pass, and a drifted tier, a broken dependency, or a failing gate turns the entire run red. Governance is part of that single pass-or-fail number, not a separate review meeting that happens, or does not, after the fact.
Governance only counts if it can stop the model. A check that merely warns is theatre with a progress bar; a gate that can refuse to let a model run or deploy is the thing that actually holds the policy true.