MLOPS & DEPLOYMENT · QUESTION 21
What is a model registry, and why is model versioning important?
On this page
A model registry is a controlled catalog for model artifacts and their metadata, such as version, training inputs, evaluation results, approval state, and deployment history. Versioning makes it possible to identify what produced a prediction, reproduce a release, compare candidates, and roll back. A registry is useful only when its records link the model to the code, data, configuration, and preprocessing that shaped it.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A model file by itself does not explain where it came from or whether it is safe to use. Teams need a reliable record of which data and code produced it, how it was evaluated, and where it is deployed. A registry gives models a managed home and lifecycle. This is especially important when several candidates, environments, and teams share responsibility for production.
A USEFUL COMPARISON
Picture it this way
A registry is like a release shelf for carefully labeled product recipes. Each entry says which ingredients and process were used, what checks it passed, and whether it is approved for use. The analogy has limits: a model also depends on runtime code and data transformations, so the artifact label alone is not enough for reproducibility.
FOLLOW THE JOURNEY
A registry connects model artifacts to their lifecycle
Trace a model from training lineage through evaluation, approval, deployment, and rollback.
A registry records lifecycle metadata; it does not automatically guarantee reproducibility unless dependencies, datasets, and transformations are also captured.
Training code, data, and configuration create a versioned model artifact with evaluation metadata; registry stages track approval and deployment history.
How to read this visual
A registry records lifecycle metadata; it does not automatically guarantee reproducibility unless dependencies, datasets, and transformations are also captured.
UNDER THE HOOD
How it works, step by step
Record lineage
Associate the artifact with code revision, data reference, parameters, and environment.
Why it matters: A team needs to explain how a model was created.
Attach validation evidence
Store metrics, test results, and relevant approval notes.
Why it matters: Deployment decisions should be traceable to evidence.
Manage lifecycle state
Mark candidates, approved versions, and deployed versions through controlled transitions.
Why it matters: A trained artifact should not become production by accident.
Track serving and recovery
Record where each version runs and retain a known-good rollback option.
Why it matters: Incidents require identifying and restoring a specific release.
OUTSIDE THE TEXTBOOK
A practical example
A team registers each demand-forecast model with its training-data snapshot, feature code revision, dependencies, and evaluation report. A reviewer approves a candidate, and the deployment system records which service environment receives it. When a later release performs poorly, the team can identify affected forecasts and restore the prior approved version.
GO A LITTLE DEEPER
Technical details that matter
- Artifacts should be immutable or content-addressed so a version cannot silently change after approval.
- Model lineage may include dataset snapshots, feature definitions, environment images, random seeds, and evaluation sets.
- Registry state transitions can support approvals and audit history but should integrate with deployment permissions.
- Large artifacts may live in object storage while the registry stores references, checksums, and metadata.
MAKE A GOOD CHOICE
When is this useful?
- Teams with multiple model versions, environments, or controlled approvals.
- Investigating a prediction or reproducing a model release.
- Coordinating gradual rollout and rollback between data-science and platform teams.
A small experiment may start with versioned files and metadata in source control or an experiment tracker. A dedicated registry becomes useful when artifact lifecycle, access, approvals, and deployment history need consistent management.
WATCH OUT FOR
Common misunderstandings
- Versioning the model file but not its data, preprocessing, or dependencies.
- Assuming registry presence means a model has passed quality or safety review.
- Allowing mutable tags to obscure the exact artifact deployed in an environment.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- A registry adds integration and governance work.
- Metadata can become incomplete if pipelines do not record it automatically.
- Reproducing behavior may still be impossible when source data or runtime dependencies are unavailable.
WHAT TO REMEMBER
Key takeaways
- 1A registry tracks artifacts and their lifecycle evidence.
- 2Reliable versioning includes data and inference dependencies, not just weights.
- 3Deployment history helps auditing, debugging, and rollback.
- 4Automation and access control determine whether registry records stay trustworthy.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
What metadata would you store with a model?
At minimum, artifact identity, code and data lineage, configuration, environment, evaluation results, approval state, and deployment history.
How does a registry differ from an experiment tracker?
Experiment tracking helps compare runs during development. A registry focuses on managing artifacts through approval and deployment, though tools may provide both.
How do you ensure a deployed model can be rolled back?
Record the exact deployed artifact and its compatible preprocessing, keep the prior version available, and test the rollback process as part of release operations.
SAY IT OUT LOUD
How to explain this in an interview
“A model registry is a managed catalog for versioned artifacts and their lineage, evaluation, approval, and deployment history. Versioning lets the team identify what produced a prediction, reproduce a release, and roll back safely. I would capture the model together with its data reference, code, preprocessing, and environment, because a weights file alone is not enough to reproduce the serving behavior.”
Connect this question to the roadmap topic it supports.