Building an AI model registry that your ML team will actually use

Every ML team eventually builds a model registry, and most of them go stale within six months. The pattern is always the same: someone builds a spreadsheet, a wiki page, or a lightweight tool, everyone agrees it is a great idea, and then nobody updates it because updating it is manual work that lives outside the training pipeline. This post is about designing a registry that ML engineers actually keep alive.

Why manual model registries fail

A model registry is a governance artefact. ML engineers do not have a governance job — they have a modelling job. If updating the registry requires them to switch tools, fill in a form, or remember to run a script after training, it will not happen. The registry drifts, then it is untrusted, then it is ignored, then it is dead.

The fix is not "remind people harder". The fix is to make the registry a downstream artefact of the pipeline, not an upstream input to it.

Design principles

• →Ingest from the pipeline, not from humans — training jobs publish, they do not ask
• →Version everything — every training run creates an immutable version, even if the model is thrown away
• →Track datasets and prompts — a model without its training data or system prompt is useless for audit
• →Expose a REST API and an SDK — humans use the UI, systems use the API
• →Make deployment a first-class field — a model in the registry that never deployed is a candidate, not a system

The minimum viable schema

You do not need 40 fields. You need six or seven, applied consistently.

• →model — logical name of the model (e.g. "fraud-detector")
• →version — semantic or hash-based version, immutable
• →dataset — reference to the exact training data snapshot, versioned
• →training_config — hyperparameters, base model, framework version
• →deployment_env — none / staging / production, plus a timestamp
• →owner — the human accountable for this version
• →evaluation — link to the evaluation report generated by CI

Everything else — cards, tags, custom metadata — is a nice-to-have layered on top of that spine.

Make it show up in CI/CD

The registry earns its keep when it becomes a gate. Wire it in so that deployment scripts refuse to promote a model that is not in the registry, and refuse to promote a version without an evaluation report attached. This makes the registry mandatory as a side effect of shipping, rather than as a policy people have to remember.

For teams using GitHub Actions or GitLab CI, that is usually a 40-line workflow step: after training, POST the artefact metadata to the registry; before deployment, GET the record and check its status field.

What to log at inference time

Registry entries should link to a monitoring stream, not contain one. At inference time, log the model version, input shape, output shape, and any drift or quality signals to your observability system. The registry stores the identity; the observability system stores the behaviour. Do not conflate the two.

How Zilonex Govern does this

Zilonex Govern ships a Python SDK that ML engineers drop into their training scripts. One decorator on the training function registers the model, records the dataset hash, and attaches the evaluation report. From that point on, the model version shows up in the Govern dashboard alongside its risk assessment, deployment status, and audit trail — with zero manual updates from the ML team.

The result is a registry that is always current, because staying current is a side effect of training, not a separate task.