What is a model registry, and how does model versioning work in production ML systems?

How to think about it

A model registry is a central catalog for deployable model artifacts, their metadata, lineage, approvals, and versions. In production, each registered version is immutable, while a controlled pointer such as champion or production selects which version a serving system should load.

The important distinction is that a registry is not merely a tidy folder of .pkl files. It connects a model to the exact code, data, feature definitions, evaluation results, and approval decision that made it safe to deploy.

Why a registry exists

Imagine a fraud service at 3:07 a.m. It is rejecting too many legitimate card payments. Someone says, “Roll back to the previous model.” The previous model might be final_v2.pkl, final_v2_retrained.pkl, or a file in an engineer’s personal bucket. Nobody knows which data produced it, whether its preprocessing code still exists, or whether it expects 41 features or 42.

That is the problem the registry solves.

A model artifact is the packaged file or collection of files needed to run a trained model. It may include weights, a serialized preprocessing pipeline, a tokenizer, an ONNX file, or other runtime assets. Large artifacts commonly live in object storage such as S3, GCS, or Azure Blob Storage. The registry stores the catalog entry, metadata, permissions, and a pointer to those artifacts.

A useful registry records at least:

• the model name and immutable version identifier;
• the training-run identifier;
• the source-code commit;
• the frozen dataset or data snapshot;
• the feature schema, meaning the expected feature names, types, and ordering;
• hyperparameters and evaluation metrics;
• the runtime or container image;
• the artifact location and checksum;
• who approved promotion and when;
• the deployment and rollback history.

The links between these objects are called lineage: the record of where a model came from and what it depends on. Lineage lets an engineer answer, “Which data and code produced the model serving this request?” without reconstructing history from Slack messages and notebook cells.

The mental model

There are four concepts worth separating:

Object	Meaning	Example
Registered model	The logical model family	fraud-detector
Model version	One immutable candidate	Version 7
Training run	One execution that produced it	Run 2026-08-01-1842
Alias	A movable name pointing to a version	champion points to 7

Version 7 does not mean “the seventh-best model.” It means the seventh version registered under that model name. A newer version can be worse. The number is an identity, not a quality score.

Immutable means that once version 7 is registered, its model bytes and core provenance must not be silently replaced. If the team retrains using the same code and data but gets different weights because of random initialization or nondeterministic hardware, it should create another version. Otherwise an audit performed next month may resolve “version 7” to different bytes than the service used today.

An alias is a mutable name that points to one specific version. For example:

model_name: fraud-detector
alias: champion
resolved_version: 7

The serving system can follow champion, while the deployment record must also save that champion resolved to version 7 at load time. The alias makes promotion convenient. The resolved version makes the event reproducible.

Older registry workflows often use lifecycle stages such as Staging, Production, and Archived. Many teams now prefer aliases such as candidate, champion, and rollback, because aliases can represent the organization’s actual deployment vocabulary and support more than one useful pointer. The exact terminology depends on the registry product.

A concrete example

Suppose a fraud team trains a gradient-boosted model on 3.2 million transactions. The training job uses a time-based validation window containing 400,000 later transactions. The resulting model achieves an area under the receiver operating characteristic curve, abbreviated AUC, of 0.923.

The job registers it as version 7 of fraud-detector:

registered_model: fraud-detector
version: 7
artifact_uri: s3://ml-artifacts/fraud-detector/versions/7/
artifact_digest: sha256-recorded-by-the-registry
code_commit: 8f31c2a
training_data: fraud-events-2026-07-31
feature_schema: fraud-features-v12
runtime_image: fraud-serving:2026-08-01
validation_auc: 0.923
training_run: 2026-08-01-1842
status: candidate

The training_data value should identify an immutable, queryable snapshot. It does not necessarily mean the registry copied 3.2 million rows into its own database. The artifact digest provides a way to detect that the binary loaded later is not a silently modified replacement.

A week later, version 8 scores 0.927 AUC. That looks better, but the team also discovers that its recall for newly created merchants has fallen by 8 percent and its 95th-percentile inference latency has risen from 18 milliseconds to 31 milliseconds. Version 8 is not automatically the winner. The decision depends on the business cost of missed fraud, false declines, and latency.

This is why the registry stores metrics and evaluation slices rather than only one headline score.

How promotion works in production

A typical workflow looks like this:

1. A training pipeline produces an artifact and registers a new version. Registration means “this candidate is recorded,” not “this candidate is live.”
2. Automated checks verify the model package, feature schema, dependency security, evaluation thresholds, and performance on important data slices.
3. A reviewer or an approval policy promotes the candidate for deployment.
4. The deployment system loads the candidate in a canary, meaning it receives a small share of real traffic. For example, version 8 might receive 5 percent of requests while version 7 remains the champion.
5. The system compares error rate, latency, business outcomes, and operational health. If the checks pass, the champion alias moves from version 7 to version 8.
6. The serving fleet reloads the selected artifact and records the resolved version in its deployment metadata.

Promotion usually changes metadata or a pointer. It should not copy and rename model files by hand. That is the mechanism that makes promotion auditable and rollback practical.

Rollback then means moving the production pointer back to the previously approved version and asking serving instances to reload it. This may not require a new application code deployment, but it is not magically instantaneous. Alias propagation, model loading, container startup, and in-flight requests still take time. A good system reports when each instance has loaded the rollback version.

The nuance that earns the senior signal

A registry is not the same thing as a deployment platform. The registry answers, “What versions exist, what produced them, and which one is approved?” The deployment system answers, “Which machines load the model, how much traffic do they receive, and are they healthy?” Some products combine both capabilities, but the responsibilities remain different.

A registry is also not a replacement for an experiment tracker. An experiment tracker records many exploratory runs and their metrics. A registry manages the smaller set of artifacts that are candidates for shared use, deployment, audit, or rollback. A tool may provide both features, but the concepts should not be confused.

The most common mistake is treating an alias as a reproducible dependency.

Common mistake: A batch job that says “use champion” may produce different results next week because champion can point to a new version. For reproducible reports, backfills, and investigations, pin the immutable version or artifact digest. Use aliases for controlled live rollout, not for historical experiments.

There is a second boundary: versioning the model weights is not enough. The feature computation, preprocessing, data snapshot, runtime dependencies, and expected schema can all change. If version 7 expects a standardized age feature but the serving code sends the raw age, the registry may correctly retrieve the old model and the service can still be wrong.

A registry adds operational cost. It needs access control, retention rules, metadata quality checks, and storage cleanup. A one-off notebook model used by one person may not need a full promotion workflow. A model shared by three teams, making financial decisions, or serving a customer-facing endpoint almost certainly does.

Failure modes to recognise

One common symptom is an error such as expected 42 features, got 41 immediately after redeployment. The model artifact was restored, but its preprocessing pipeline or feature schema was not versioned with it. The fix is to package or pin the preprocessing logic and validate the input contract before serving.

Another symptom is that an alias was moved to version 8, but production metrics continue to look exactly like version 7. The serving fleet may cache the artifact and never poll for alias changes. The control plane changed, but the data plane, meaning the request-serving process, did not reload. A deployment must make alias refresh and instance-level loaded-version reporting explicit.

What they’ll ask next

How is a registry different from Git?
Git is excellent for source code and small text-based configuration. It is not, by itself, a record of training data snapshots, evaluation decisions, deployment state, or large binary artifact retention. A registry connects those pieces. Git should still record the code commit used to train the model.

Can a registry roll back a bad model by itself?
It can identify and repoint to the previous version, but the serving system must reload that version and verify that its feature contract is still compatible. Rollback is a registry-plus-deployment operation, not just a database update.

What must be recorded to reproduce a model?
At minimum: immutable model bytes, code commit, data snapshot, feature and label definitions, preprocessing version, hyperparameters, runtime environment, random seed where relevant, and evaluation results. Even then, exact bit-for-bit reproduction may require controlling hardware and nondeterministic operations.

Say this in the interview

“A model registry gives every deployable model artifact an immutable version with its data, code, environment, metrics, and lineage; production promotes a tested version through a controlled alias, while retaining the exact version needed for audit and rollback.”