Ask a team where their production model came from, and you’ll often get a story: “It’s the file Priya put in the bucket, I think from the March experiment.” That works until Priya is on leave and the file needs to be rolled back. A model registry replaces the story with a record. It’s one of the cheaper pieces of MLOps to adopt and one of the first that pays for itself.

What a Registry Actually Is

A model registry is a catalog of model versions with enough metadata to answer three questions: what is this model, where did it come from, and what state is it in? It is not the same as storage. Weights sit in an artifact store; the registry holds pointers and context. That distinction matters, because the value is the traceability and the controlled state changes, not the file location.

You can use a dedicated tool, a feature of a broader MLOps platform, or even a disciplined naming scheme plus a metadata table when you’re starting out. Which you choose matters less than whether everyone uses it as the single source of truth.

What to Record for Each Version

A version entry that lists only a file path is barely better than nothing. A useful one captures:

• Identity: model name, version number, and the location of the artifact, ideally with a checksum.
• Lineage: the training run that produced it, which links to code commit, data snapshot and configuration. Our guide on reproducible training runs covers what that run record should contain.
• Evaluation results: the metrics on the agreed evaluation set, plus which evaluation set and version.
• Intended use and limits: what it’s for, known weak spots, and input assumptions.
• Interface: input and output schema, so downstream consumers know what to expect.
• Ownership: a named team or person responsible.
• Status: the current stage in the lifecycle.

If you work in a regulated area or handle sensitive data, add whatever documentation your compliance process requires; requirements vary, so confirm them with the relevant specialists.

Stages and Promotion

Most registries use stages. The names vary, but the idea is consistent: a model moves through gates, and each move is a deliberate, recorded decision.

1. Registered / candidate: a trained model exists and has metrics attached.
2. Staging: it’s being validated in an environment that resembles production, with integration tests and perhaps shadow traffic.
3. Production: it serves real users, and exactly which version is live is unambiguous.
4. Archived: retired but kept for rollback or audit purposes.

The key rule: nothing reaches production except by promotion from staging. No one copies a file straight to the serving location “just this once.”

Write Down the Promotion Criteria

The gates are only meaningful if they are explicit. Before a candidate can move to staging or production, define what must be true, for example:

• It beats or matches the current production model on the agreed evaluation set, including important subgroups, not just the headline metric.
• It passes schema and integration tests against the serving code.
• Latency and resource use are within the budget for the endpoint.
• A reviewer who didn’t train it has signed off.
• A rollback plan exists and names the version to return to.

Automate what can be automated, such as metric thresholds and schema checks, and leave human approval for judgment calls. Record who approved and when.

A Hypothetical Example

A team keeps model files in a shared bucket with names like ranker_final_v2_new. After an incident, they can’t tell which file production was serving. They adopt a registry and make two rules: every training run registers its output automatically with the run ID attached, and the serving layer loads models only by registry name and stage, never by a file path.

Now a new candidate is registered after training, evaluated automatically, and promoted to staging when it meets the written thresholds. After a week of shadow traffic and a reviewer’s sign-off, it is promoted to production, and the previous version is marked as the rollback target. When a problem surfaces later, rollback is a stage change instead of an archaeology project.

A Metadata Checklist

Field	Why it earns its place
Artifact location and checksum	Confirms you’re serving the file you think you are
Training run ID	Connects the model to code, data and config
Evaluation set and metrics	Makes comparisons between versions fair
Input / output schema	Prevents silent breakage downstream
Owner	Someone to ask, and someone accountable
Stage and history	Shows who promoted it, and when
Known limitations	Keeps misuse and surprise down

Common Mistakes

A few traps show up repeatedly. Registering models without lineage defeats the purpose. Allowing manual overrides that bypass promotion makes the registry untrustworthy within weeks. Treating the registry as write-only, with nobody reading it, means stale entries pile up; assign someone to prune and archive. Finally, comparing candidates against differing evaluation sets makes “better” meaningless, so version the evaluation data too.

Frequently Asked Questions

Do small teams need a model registry? A lightweight version, even a table with a consistent process, helps from the first production model. Add tooling as complexity grows.

Is a registry the same as an experiment tracker? No. Trackers log many experimental runs; the registry holds the subset you’ve decided are candidates for deployment, with lifecycle stages.

Should the registry store the model files themselves? Some tools do, others point to external storage. Either is fine as long as the link and checksum are reliable.

Who should approve promotion to production? Someone other than the model’s author, such as a peer or a team lead, and the approval should be recorded.

How do we handle rollbacks? Keep the previous production version in a state that can be restored quickly, and make the rollback a documented, tested step.

Next Step

Take the model currently in production and try to fill in every row of the checklist above. The blanks tell you exactly what your registry needs to capture first.