A model registry is a central, versioned catalog of trained models and their lifecycle stage — staging, production, archived — providing one authoritative answer to "which model is currently live?" instead of scattered files and tribal knowledge.
The Standard Lifecycle Stages
| Stage | Meaning |
|---|---|
| None / Staging | A newly registered model, undergoing validation before production consideration |
| Production | The currently live, deployed model version |
| Archived | A previously used version, retained for rollback and audit purposes |
Python Implementation — MLflow Model Registry
import mlflow
from mlflow.tracking import MlflowClient
client = MlflowClient()
# Register a model from a completed, tracked run
model_uri = "runs:/<run_id>/model"
registered_model = mlflow.register_model(model_uri, "loan_approval_model")
# Promote it through stages after validation
client.transition_model_version_stage(
name="loan_approval_model",
version=registered_model.version,
stage="Staging",
)
# After passing validation checks -> promote to Production
client.transition_model_version_stage(
name="loan_approval_model",
version=registered_model.version,
stage="Production",
)Loading the Current Production Model, Unambiguously
import mlflow.sklearn
# Always loads whatever is CURRENTLY marked "Production" -- no hardcoded filenames,
# no guessing which version is live
production_model = mlflow.sklearn.load_model("models:/loan_approval_model/Production")
predictions = production_model.predict(X_new)This is the registry's key operational benefit: serving code always asks for "the Production version," never a hardcoded file path — promoting a new model to Production automatically makes it the one served, with no code changes or redeployment of the serving logic itself needed.
A Rollback, Made Trivial
# If the new production model regresses, roll back instantly --
# no retraining, no re-deriving the old model, just a stage change
client.transition_model_version_stage(
name="loan_approval_model", version=3, stage="Production", # the KNOWN-GOOD previous version
)
client.transition_model_version_stage(
name="loan_approval_model", version=4, stage="Archived", # demote the problematic new one
)Practical Use Cases
- Teams managing multiple model versions across development, staging and production simultaneously
- Fast, safe rollback when a newly deployed model underperforms
Common Mistakes
- Deploying models via hardcoded file paths ("model_v3_final_FINAL.pkl") instead of a registry's stage-based lookup — this makes tracking the current live version and rolling back much harder.
- Promoting a model straight to Production without an intermediate Staging validation step.
Interview Relevance
Q: "How does a model registry make rollback faster than retraining?" The previous, known-good model version is already trained and stored in the registry — rolling back is just a stage transition (marking the old version "Production" again), instantly redirecting serving code to it, with no retraining or redeployment of new code required.
Practice Question
Sketch the sequence of registry operations you'd perform when promoting a newly trained model version 5 to Production, while safely retiring the current version 4.
