Model Registry

Training produces a file, and a file on its own answers almost none of the questions that matter.

Which data made it, which code, which hyperparameters, how well it scored, and is it allowed in production.

A model registry is the system of record that attaches those answers to the artefact.

Each entry is a named model with numbered versions, and each version carries its lineage.

That lineage points at the training run, the dataset version and the commit that produced it.

Evaluation metrics are stored alongside, so two versions can be compared without rerunning anything.

Versions move through stages, typically staging, production and archived.

Promotion between stages is an explicit, recorded, usually reviewed action.

That record is what turns which model is live into a question with an answer.

Deployment then references a name and a stage rather than a path on a storage bucket.

Rolling back becomes repointing at the previous version instead of hunting for a file.

It also underpins audit: a regulator asking why a decision was made needs the exact model and its provenance.

The registry is where a model card and its intended-use notes belong, next to the weights.

For systems built on hosted language models, the equivalent discipline is pinning model versions and recording prompts.

The principle is the same either way: nothing reaches production without a recorded identity.