Skip to content

Model Registry

Governance register — instantiates Model-Based Regulation

The system of record for every regulating model — its lineage, assumptions, owner, approvals, and deployment status — so any model in production can be traced, re-approved, or rolled back.

Model Registry is the system of record for the models doing the regulating. Every version is entered with its lineage — the data and code it came from — its stated assumptions, the named owner accountable for it, the evaluations it passed, who approved it, and where, if anywhere, it is currently deployed. It computes nothing and decides nothing about the world; its entire job is to make the population of models legible and governable — to answer, at any moment, which model is live, who owns it, what it assumes, how it was approved, and what to fall back to if it must be pulled. In an archetype full of mechanisms that build and test models, the registry is the one that remembers them.

Example

An autonomous-vehicle company runs dozens of perception models across its fleet, retrained every few weeks. When one vehicle behaves oddly at dusk, the safety team needs answers in minutes, not days: which perception model was running on that vehicle that evening, what data it was trained on, what it assumes about low-light conditions, who owns it, and whether an earlier version can be restored fleet-wide tonight.

The Model Registry is where those answers live. The suspect model's entry shows its version and training-data snapshot (the audit trail), the perception lead accountable for it (the owner), the fact that only the safety board — not an individual engineer — was authorized to promote it to the fleet (the authority scope), and its recorded assumption that camera exposure is auto-corrected before inference (the assumption register) — the very assumption that turns out to fail at dusk. Because the prior version and its approval are on record, the team rolls back within the hour and reopens that assumption for review. None of this required rerunning a single test; it required only that everything had been written down in one place.

How it works

A registry is not a folder of files; it is defined by the links it forces:

  • One entry per version, immutably. Each model version is a distinct, timestamped record, so "which model was live then" always has a single answer.
  • Provenance is attached, not assumed. Training data, code, parameters, and the stated assumptions travel with the version, so a model can never be in production without its context.
  • Accountability and authority are named. Every version carries its owner and the scope of who may approve or deploy it, turning "someone shipped it" into a named, bounded act.
  • Deployment and rollback are first-class. The registry always knows what is live and what the previous good version was, so a pull-and-revert is a lookup rather than an excavation.

Tuning parameters

  • Versioning granularity — every retrain versus only promoted releases. Fine granularity gives perfect traceability but floods the registry; coarse granularity is tidy but loses intermediate lineage.
  • Metadata depth — how much context each entry must carry before it can be registered. Richer entries govern better but raise the friction of shipping.
  • Approval gates — how many sign-offs, and from whom, before a version can deploy. Tighter gates catch more but slow response and tempt teams to route around the registry.
  • Immutability vs. editability — whether entries can ever be amended. Strict immutability preserves the audit trail; some editability is needed for corrections without eroding trust.
  • Rollback retention — how many prior good versions stay instantly restorable. Deeper retention is safer but costs storage and upkeep.

When it helps, and when it misleads

Its strength is that it turns a sprawling, silently-changing population of models into something traceable, accountable, and reversible — the substrate that model-risk governance (in banking, the discipline codified by supervisory guidance such as the Federal Reserve's SR 11-7) simply assumes exists.[1] It is what lets an organization answer "what was live, who owns it, and what do we revert to" without a forensic dig.

A registry records only what it is told, so its great failure mode is drift between the record and reality — a model quietly patched in production while its entry says otherwise, an assumption that changed but was never logged. Then the registry radiates false confidence: everything looks governed because everything is written down, even when the writing is stale. It is also easily reduced to compliance theatre, entries filled to satisfy an auditor rather than to be used. The discipline is to make the registry the only deployment path (so reality cannot diverge from the record), require the owner to re-attest assumptions on a cadence, and reconcile "what's registered" against "what's actually running" rather than trusting the entry.

How it implements the components

Model Registry fills the governance-record slice — the components that make the model population accountable, not the ones that build or test it:

  • audit_trail — the immutable, timestamped version history: lineage, training data, evaluations, and deployment events.
  • model_owner — each version carries the named party accountable for it.
  • authority_scope — the registry records and enforces who is authorized to approve and deploy each model, bounding the act of shipping.
  • assumption_register — the stated assumptions each version depends on are held with it, so they can be re-examined when reality shifts.

It produces none of the substance it stores: the models come from State-Space Model and System-Identification Experiment, the evaluations from Champion–Challenger Evaluation, Scenario Testing, and Historical Replay, and the safe state to revert to is defined elsewhere.

Notes

"Roll back to the previous version" is not the same as "fail safe." The registry can tell you which prior model to restore, but restoring it is a deliberate governance act, not an automatic runtime response to a model going wrong. The safe state a regulator drops into on its own when a model fails is a separate mechanism; the registry supplies the option, not the reflex.

References

[1] Model risk management — governing models as a source of risk, including inventory, ownership, validation, and controls — is a recognised supervisory discipline; the U.S. Federal Reserve and OCC guidance known as SR 11-7 is a well-known statement of it. A model registry is the inventory-and-lineage substrate such governance presumes; it does not by itself constitute the validation that governance also requires. ↩