Model Registry: Source of Truth for Deployed Models

WHY IT EXISTS: Training a model produces more than just weights. It produces a specific combination of code, data snapshot, hyperparameters, and metrics. Without a system to pin these together, teams lose reproducibility. A model registry exists to solve the artifact identity crisis: it answers the question "what exactly is running in production right now, and how do I get back to it?" It closes the gap between experiment tracking, which is research-oriented, and production operations, which demands stability and auditability.

THE MENTAL MODEL: Think of it as a combination of a library card catalog and a state machine for software releases. Each registered model is a catalog entry that points to immutable artifacts, but the entry also carries a lifecycle stage such as development, staging, or production. The registry does not just store files; it governs promotions. Like a library, the catalog is useless if the cards are blank or the books are shelved at random.

HOW IT WORKS: A registry ingests a model artifact, typically a serialized file or container image, along with metadata that includes the training run ID, dataset version, metrics, and dependencies. It assigns a versioned identifier and exposes stage labels. When a deployment pipeline requests the production model, it queries the registry by stage rather than by opaque file path. Advanced registries also capture lineage, linking the model back to the experiment and training data that produced it. Access control separates who can register a model from who can approve a stage promotion.

WHEN TO USE IT: Use a model registry when you have more than one model in production, when multiple engineers or teams share artifacts, or when compliance requires an audit trail of what was deployed and when. It is also critical for A/B testing scenarios where two versions must coexist, and for automated retraining pipelines that need to compare a challenger model against the current champion before swapping them.

WHEN NOT TO USE IT: Do not introduce a registry for a single static model that never changes, or during early prototyping when the cost of ceremony exceeds the value of traceability. If your team lacks the discipline to enforce stage transitions and metadata standards, the registry becomes an expensive file dump that adds latency without adding clarity.

ONE CANONICAL EXAMPLE: A fraud detection team retrains its gradient boosted model weekly. The training pipeline completes and logs a new version to the registry with an F1 score of 0.94. A human reviewer promotes this version from staging to production after shadow testing. The serving microservice queries the registry for the current production tag and downloads the associated artifact. When monitoring detects drift two weeks later, the team rolls back in minutes by repointing the production tag to the previous registered version, avoiding a full retraining cycle.