Model registry & promotion
The single source of truth for which model exists, how it was trained, and what's in production. Versioning, stage promotion, and the governance gate that keeps unreviewed models out of prod.
What you'll learn
- What a model registry tracks beyond experiment metrics
- Stage promotion (Staging → Production) and aliases (champion/challenger)
- The promotion gate as the governance and compliance choke point
Before you start
MLflow tracking answers “what did I try?” The model registry
answers a different, scarier question: “which model is in production right now, how
was it trained, and who approved it?” If your answer today is “the model.pkl on
that server, probably from the notebook Raj ran in March,” you need a registry.
What a registry tracks
A registry sits on top of your tracked runs and adds a governed layer:
- A registered model with a name (
churn-classifier). - Versions (1, 2, 3…), each pointing to a specific run, its artifacts, metrics, and the exact data/code that produced it.
- Stages —
None → Staging → Production → Archived— or modern aliases (champion,challenger,shadow) that let you point a label at a version without renaming anything downstream.
So “the production model” becomes a queryable pointer, not tribal knowledge. Your
serving layer loads models:/churn-classifier@champion and you can roll back by
moving the alias.
The promotion gate
The registry’s real value isn’t storage — it’s the gate. Promoting a version to Production should require evidence: eval results, a model card, a bias audit, a human sign-off. Try to promote a model before it’s ready:
That gate is what turns “someone copied a pickle to prod” into a reviewed, logged, reversible event — and it’s where governance and responsible-AI checks get enforced.
Quick check
Quick check
Next
A registry is only trustworthy if its lineage is — which means versioning the data too, and proving the model works with ML testing before you promote it.
Practice this in an interview
All questionsA model registry is a centralised store that tracks every trained model artifact alongside its metadata — hyperparameters, training data version, evaluation metrics, and lineage. Versioning assigns unique identifiers to each artifact and manages lifecycle stages so teams can promote, roll back, and audit models without manual file management.
Register every candidate as an immutable, versioned artifact, then move it through environments (dev to staging to prod) gated by automated checks rather than promoting straight to prod. In modern MLflow you use aliases like champion and challenger instead of the deprecated stage labels, and promotion is a governed, auditable action with sign-off and an easy rollback by repointing the alias. Always validate in staging and roll out progressively (canary or shadow) before full traffic.
Experiment tracking logs every run, its parameters, metrics, and artifacts, so you can compare and reproduce experiments during development. A model registry is the curated, governed catalog of the few models you actually intend to deploy, with versioning, stage or alias management, approvals, and lineage. You need both because tracking gives breadth for exploration while the registry gives the controlled, auditable path to production.
The ML lifecycle spans eight phases: problem framing, data collection and validation, feature engineering, training and experimentation, offline evaluation, deployment, production monitoring, and retirement or retraining. Each phase has distinct owners, artefacts, and failure modes that an MLOps practice must systematise.