What is a model registry?

A model registry is the central catalog where trained machine learning models are versioned and promoted through defined stages, typically staging, production and archived, with a record of who promoted which version, when and with what approval. It is the handoff point between the people who train models and the people who serve them in production: a tool such as the MLflow Model Registry, as one example of the category among several available, records for each version the training metadata, the owner and the history of stage transitions, so a promotion to production leaves a verifiable record instead of a Slack message. The registry handles the where: where the authoritative version of a model lives and how a team moves between versions in a traceable, reversible way. It does not cover how that model was reached through training attempts, nor what happens to it once it is running in production: those are distinct phases of the lifecycle, before and after the registry.

Why it matters

Without a registry, promoting a model to production happens by email or chat message: a data scientist announces the new version is ready, someone copies it to a shared path, and nobody has a reliable record of which file matches which experiment, who approved the switch, or how to roll back if the new version performs worse than the old one. Rollback becomes folder archaeology instead of a command. With a registry, every version carries a unique identifier, a declared stage and a history of transitions: the question "what is the real model in production right now" always has one verifiable answer, without asking anyone. A version in the registry can point to associated metadata, such as a model card documenting intended use and limitations, without the registry writing or owning it; upstream, the trials that led to that version stay the responsibility of experiment tracking.

An enterprise example

A lending company has a data science team that trains a risk-scoring model and a platform team that serves it at branch offices. Without a registry, the two teams coordinate versions by hand: the data scientist sends an archive, the platform loads it whenever there is time, and during an audit nobody can say with certainty whether the version served in a given month was the validated one or an earlier one left behind by mistake. With a registry, the data scientist promotes the version from staging to production through an explicit action that requires approval; the platform always reads the current stage instead of copying files by hand; and if something goes wrong, rolling back to the previous stage is an operation, not a search. The MLOps discipline provides the overall framework; the registry is the concrete tool that makes it verifiable who released what.

Why it matters for decision makers

A promotion audit trail is not a big-tech luxury: it is the difference between being able to answer a regulator or a client asking "who approved the version of this model that made this decision" and not being able to. The cost of putting it in place is low compared to discovering it is missing during an inspection, or after a production incident caused by an unvalidated version that ended up in service through a manual copy mistake.