Model registry and rollback

A model registry is the system of record for model versions (and often prompts): what’s live, who approved it, lineage to the training run, and how to roll back fast. MLflow’s Model Registry documents versioning, aliases, tags, lineage, and collaborative lifecycle management—the same ideas appear across cloud registries.

<!-- IMAGE: Staging → Production pointer with rollback arrow -->

Without registries, incidents become archaeology. Rollback is a safety feature. Google Cloud’s level-2 architecture lists a model registry beside the orchestrator, feature store, and metadata store.

1. Register artifact + metrics + card / notes.
2. Promote through stages or aliases (e.g., champion).
3. Pin production pointers to a version or alias.
4. Roll back by repointing—not by “find the old zip.”
5. Audit who changed what and when.

A library’s card catalog: you need the edition, not a pile of unlabeled books in the hallway.

Write your current “what’s in prod?” answer in one sentence—including version id. If you can’t, you need a registry habit.

⚠️ Myth: Git alone is a model registry.

✓ Reality: Helpful for code; you still need artifact pointers, stage metadata, and lineage to data/runs.

⚠️ Myth: Rollback is rare so process can be informal.

✓ Reality: Informal rollback fails exactly when stress is highest.

• MLflow Model Registry: https://mlflow.org/docs/latest/ml/model-registry/ ↗
• MLflow Tracking (lineage source): https://mlflow.org/docs/latest/ml/tracking/ ↗
• Google Cloud MLOps: https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning ↗
• Course 25 model cards; Course 17 prompt versioning