The Registry as a Promotion Gate
Why a model registry is a workflow rather than a storage location, what a stage transition should require, and the difference between a registry that records decisions and one that enforces them.
A model registry is often described as a place to store models. Object storage is a place to store models, and it costs nothing. What a registry adds is a controlled transition: a named model has versions, versions occupy stages, and moving between stages requires something to happen. If moving a model to production is a dropdown anyone can change, the registry is a filing cabinet.
What a promotion should require
Evaluation evidence. Metrics on a held-out set, computed by the platform rather than reported by the author, on a dataset version recorded alongside the result. Self-reported metrics are the failure this exists to prevent.
A comparison against the incumbent. Not just a score, but a score against the model currently in production, on the same evaluation data, with enough repetitions or enough test set size to say whether the difference exceeds noise.
Provenance. The training run ID, and from it the code, data and environment versions. A model whose lineage cannot be resolved should not be promotable, and enforcing that at the gate is how the discipline upstream gets maintained.
Approval where the risk warrants it. For a model with regulatory or safety exposure, a named human sign-off with a timestamp. For a low-risk model retrained daily, automation with a rollback path is better, since a human rubber-stamping a daily promotion adds delay and no scrutiny.
Stages, and what they mean
The conventional stages, some form of none, staging, production and archived, are useful only if each has a defined meaning and entry criteria. A version in staging should be one that has passed evaluation and is being validated in a production-like environment. A version in production should be one serving traffic. Archived should mean superseded but retained for audit and rollback.
Two properties matter more than the specific names. Transitions must be recorded with actor and timestamp, so the question "who put this in production and on what evidence" has an answer. And the registry must be the source of truth for what is deployed, which means the deployment system reads from it rather than being configured in parallel. A registry that says production while a different model serves traffic is worse than no registry, because it is consulted and it is wrong.
When it breaks
Registries drift from reality. Deployments happen through a mechanism that does not update the registry, and the two diverge within weeks. Reconciliation, comparing what the registry claims against what serving endpoints actually load, belongs as a continuous check.
One production stage is not enough. Real systems serve several models simultaneously: per region, per segment, per experiment arm. A single production slot forces teams to encode that in model names, which loses the version history that the registry existed to provide. Aliases or tags pointing at versions handle it properly.
The gate becomes a formality. If promotion always succeeds, the criteria are not doing work. A gate that has never blocked anything is either measuring nothing or measuring something nobody would have violated, and it is worth checking which.
Rollback needs more than an old version. Reverting a model means reverting whatever else changed with it: feature definitions, preprocessing code, prompt templates. A registry that versions only the weights makes rollback look simple and leaves it incomplete, which is discovered during an incident.
12 flashcards for this concept
Click a card to reveal the answer.