A lender’s credit model is retrained every month. In March a regulator asks which model decided a particular loan in January, what data trained it and how it was tested. With a registry, the answer is a lookup: version 23, trained from a named dataset snapshot by a named pipeline run, approved by the risk team after passing a fairness check, deployed January 4, replaced February 2. Without one, the answer is a search through notebooks and old buckets.
Registries usually store the model file or a pointer to it, a version number, lineage (code, data and training run), evaluation results, tags and an alias or stage such as “staging” or “production”. Deployment tools read the alias, so promoting or rolling back a model is a change in the registry rather than a manual file copy. That makes canary deployments and rollbacks quick, and gives model risk management and audit trails a reliable record.
Teams that build on hosted models still need a registry-like record, even when they don’t own the weights: which provider model and version each feature uses, which prompt version it is paired with, and the eval results that justified the choice. Some registries now hold prompts and agent configurations alongside models for that reason.
A registry is part of MLOps and supports wider AI governance. It records what was approved; it doesn’t make a model good, so it is only as useful as the evaluation evidence attached to each version.
Sources
- MLflow: ML Model Registry — Describes a centralized model store, APIs and UI for managing a model's lifecycle, with lineage to the run that produced it, versioning, aliases and metadata tags; checked October 24, 2026.
- Google Cloud: Introduction to Model Registry — Describes a central repository for managing the lifecycle of ML models, organizing and tracking versions and deploying a chosen version; checked October 24, 2026.