Model registry

What is a model registry?

A model registry is a versioned catalogue of trained machine learning models. Each model has a name, and every training run you keep becomes a numbered version underneath it. A version carries its lineage with it: which data trained it, which code produced it, and which run it came from.

It sits in the operations half of MLOps, between the experiment tracking that records your training runs and the model serving that answers live requests. The problem it solves is mundane: a trained model saved as a file on someone's laptop is not deployable and not auditable. Nobody else can reliably load it, and once it reaches production nobody can say which version is answering.

What a registry stores

The examples below use MLflow, whose model registry is also hosted inside Databricks Unity Catalog and mirrored by the model registry in Azure Machine Learning.

• Registered model. A named container, for example churn_prediction, that holds every version of one model.

• Model versions. The first model you add becomes version 1, and each later registration under the same name increments the number, so you can always roll back to one that worked.

• Aliases and tags. An alias is a movable label such as champion that points at whichever version is live. MLflow deprecated its named model stages (such as Staging and Production) in favour of aliases and tags, since a version can carry more than one alias and a Champion label can move between versions.

• Lineage and metadata. Each version links back to the run that produced it, with its parameters, metrics, training-data reference and owner. This is the data lineage that lets you reproduce or explain a model months later.

Promotion, approval and the audit trail

A version moves through the registry from candidate to production: you reassign an alias, or in Azure Machine Learning you route deployment traffic to a chosen version. Either way a gate stands before it goes live: registering a model is not the same as approving it, and a sound setup records who signed off and why.

That record matters legally. For a high-risk AI system, the EU AI Act expects the provider to keep technical documentation up to date (Article 11) and to log events automatically over the system's lifetime (Article 12). A registry is where much of that audit trail lives: which version, trained on which data, was in production when.

Model registry versus experiment tracking

The two often live in the same tool but do different jobs. Experiment tracking records every training run; the registry keeps only the models worth deploying and manages what happens to them, from promotion to model serving to a rollback when model drift shows up. A promising run is promoted into the registry as a version, and the registry answers which version is live.

What to watch out for with a model registry

Capture the lineage at registration rather than afterwards, because a version with no training-data reference, code link or metric is almost impossible to judge later. And connect the registry to production metrics, so a live version that starts slipping is visible instead of just neatly filed away.