Skip to main content
A run id is a fact about an experiment. A model version is a decision: this is the one we are willing to serve. Registering turns the first into the second. Without it, “which model is in production” and “which run produced the previous version, and who promoted it when” are answerable only by somebody who remembers a run id.

​
Register a version

Version numbers increment on their own; there is no naming step. The run has to have been exported first, which --then export at submission does for you. Base models and externally supplied weights belong on the line too, or the first entry is missing:
--desc is the model’s description and belongs on the first registration.

​
Read and move the line

Promoting a version archives the previous production one. There is exactly one production version at a time; with two, the reason this line exists is gone. Versions are immutable. A version pins a run id and a weight path, so changing weights means registering a new version. If a version a deployment already references could change content, “which version is live” would stop being answerable.

​
Point a deployment at the line

Use the model registry as a deployment’s source and leave the version empty to select the current production version when creating a deployment revision:
Each deployment revision pins the version it resolved. After tp model promote, create a new deployment revision from the same source to serve the newly promoted model. Select a particular version explicitly with "version": 3.

​
Three things called version

They do not overlap, and it is worth keeping them apart: Canary and rollback belong to the deployment revision layer. The registry does not duplicate them: two places able to express “which one is running” would fork immediately.

​
Choose the project’s release policy

In Projects → Settings → Release policy, choose Require passing evaluation to require evidence before production promotion or deployment. Existing projects default to Flexible experiments. Strict release requires a successful training run with declared evaluation suites and gates, a completed benchmark of the selected export, and passing scores. A relative gate also needs baseline scores under matching benchmark configuration. Missing, pending, failed or stale evidence blocks release for everyone, including administrators. The refusal explains what needs to be completed. The training project follows its artifact into the model registry. A Deployment also keeps its project for its lifetime; changing revisions or rolling back cannot drop that requirement. A replacement candidate is checked again before launch or traffic promotion. An already serving revision keeps serving after a policy change. For external weights, name the project explicitly:
External weights can be catalogued, but cannot satisfy strict release without verified training and evaluation evidence. Leaving an external model unbound does not apply a project policy to it. This setting is not a deployment-wide restriction on all external models. Models awaiting evaluation can still be registered as drafts. The legacy check for an explicitly failed evaluation still applies at registration. Disabling a strict requirement is a separate project-management action recorded in the audit; there is no automatic administrator exception to strict release.

​
Flexible experiments

In flexible mode, an explicitly failed evaluation blocks ordinary artifact registration and deployment. Pending or absent evaluation does not. Administrators retain the existing override in this mode. Every version on the line carries the verdict from its training run. A number on a version line with no evaluation behind it is just a path.

​
Check it worked

The new version appears with its run id and notes, and exactly one row is marked production.

​
Next

Deploy a version · Playground · Reflow · The Models page