A model registry is a central catalog that tracks trained models, their versions, metadata, and lifecycle stage (like staging and production)…
See the problems that unversioned models create.
Models change constantly — retrained on new data, tuned with new parameters, swapped for a better base. Without versioning, a team quickly loses track: which exact model is in production, how it was built, whether the new one is actually better, and how to get back to the last good one if it regresses.
Versioning fixes this by treating every trained model as a distinct, immutable, numbered artifact with a record of how it was made. That record is what lets you reproduce results, compare versions fairly, and roll back with confidence.
Learn the catalog that centralizes model versions and their metadata.
A model registry is the central catalog for all this. For each model it stores the versions, and for each version it keeps the artifact (or a pointer to it) plus metadata: who trained it, when, on which dataset version, with which parameters, and its evaluation metrics. It also records the lineage — the data and code that produced it.
This makes the registry the single source of truth. Anyone can look up what models exist, how they perform, and which version is deployed where, instead of that knowledge living in one person's head or a scattered folder of files.
Move versions through stages toward production safely.
A registry attaches a lifecycle stage to each version — commonly something like development, staging, and production. A new version is registered, evaluated and tested in staging, and only promoted to production when it passes. Deployments reference the stage ('serve the production model'), so promoting a version updates what's live without changing app code.
This makes rollback trivial: if a promoted version misbehaves, point production back at the previous known-good version. The stage-based flow turns model releases into a controlled, reversible process.
Use lineage for reproducibility and version more than the model.
Because a version records its lineage — the exact data, code, and parameters — you can reproduce a model, audit how a decision-making system was built, and debug a regression by comparing what changed between versions. Reproducibility is a core reason registries exist, especially in regulated settings.
The idea extends beyond model weights. Version your datasets (so 'trained on data v3' is meaningful), and for LLM apps, version prompts and configurations too, since a prompt change alters behavior as much as a model swap. Together these give end-to-end traceability.
Watch for: overwriting a model in place instead of registering a new immutable version (you lose history and rollback); logging the model but not the dataset version or parameters (you can't reproduce it); deploying by copying files around instead of promoting a registered version; and versioning the model while leaving prompts and configs untracked, so behavior changes are invisible.
A model registry is the central catalog of models, their immutable numbered versions, metadata, lineage, and lifecycle stage. Versioning answers which model is live and how it was built, enabling reproducibility, fair comparison, controlled promotion (dev to staging to production), and easy rollback by re-pointing to a known-good version. Extend versioning to datasets and, for LLM apps, prompts and configs, so behavior changes are traceable — never overwrite a model in place.
Your team keeps overwriting 'model.bin' on the server and can't tell what's deployed. Describe how a registry with versions and stages would fix this, what metadata you'd record per version, and how you'd roll back a bad release in minutes.
Why do models need versioning?
Immutable, numbered versions with build records prevent losing track of what's deployed and enable reproducibility, comparison, and rollback.
What does a model registry store for each version?
The registry is the single source of truth, cataloging versions with the metadata and lineage needed to understand and reproduce each one.
How do lifecycle stages help deployment?
Stage-based promotion makes releases controlled and reversible, with the deployment pointing at whichever version holds the production stage.
What should you version besides the model weights?
End-to-end traceability requires versioning data and prompts/configs too, or behavior changes become invisible and irreproducible.