Aliases, Stages and Mutable Pointers

Two engineers promote a model on the same afternoon. One sets "Production" on version 17, the other sets it on version 18, and neither is told that the other did. Which model is serving depends on which write landed last and on whether the serving fleet re-reads the registry each request, at each deploy, or at process start. The artefacts are identical in both worlds; the only thing that differs is a pointer, and pointers are where registries get their incidents.

Immutable versions, mutable names

A registered model version is an immutable record: it points at fixed artefact bytes, a training run and a data snapshot. Consumers, though, do not want to say "version 17". They want "the production model", a name whose meaning changes over time. The registry reconciles the two with a mutable pointer layered over immutable versions.

MLflow's alias feature states this directly: an alias is "a mutable, named reference to a particular version of a registered model" (MLflow, Model Registry). Moving champion from version 17 to 18 is one metadata write; the artefacts do not move, and rolling back is the same write in reverse. Cloud registries have equivalent constructs under other names (labels, tags, stage fields).

Alias versus stage

A stage is a lifecycle position drawn from a fixed vocabulary (for example none, staging, production, archived), usually with at most one version per stage. An alias is an arbitrary name you define, and several names can exist at once: champion, challenger, canary, eu-prod.

Stages encode a single linear pipeline, which is tidy until a team runs two production regions with different promotion cadences, or a champion and a challenger side by side. Aliases model those cases without bending a vocabulary to fit. The cost is that aliases carry no built-in meaning, so a team must agree what champion implies and who may move it. A free-form pointer without an owner is worse than a rigid stage with one.

Resolve late or resolve early

The decision that matters is when the name becomes a version.

• Resolve at deploy time. The deploy pipeline looks up champion, records the concrete version number in the deployment manifest, and serves that. Rolling back means redeploying a previous manifest. The running fleet cannot change under you.
• Resolve at request or poll time. Serving looks up the alias on a timer or per request. Promotion takes effect without a deploy, which is fast and is also how a mistaken pointer move reaches all traffic within one poll interval.

For most teams the first is the safer default, because the thing being served is then always a recorded fact rather than a lookup that might have changed. Late resolution earns its place when you need instant switch-over, and then it should come with the same gates a deploy would have had.

Making a pointer move safe

A pointer write is a production change and deserves the controls of one:

1. Only the promotion job's identity may move champion; humans move challenger.
2. The move is conditional: "set champion to 18 only if it is currently 17", so two concurrent promotions cannot both win silently.
3. Every move is logged with who, when and the previous value, which makes rollback an audit query.
4. Serving logs the resolved version on every prediction, so incidents can be attributed to a version rather than to a name.

When it breaks

Name drift. champion means the best model on last month's evaluation in one team and the one currently serving traffic in another. Define the alias in the model card.

Cache staleness. Replicas that cache the resolution disagree for the length of the TTL, so a rollout is briefly a mixed fleet. Treat a cache TTL as part of the rollout window.

Orphaned pointers. Deleting a version that an alias still references turns the next lookup into a failure at the worst moment. Block deletion while any alias points at the version.

For the gate in front of the pointer, see the registry as a promotion gate; for the fallback story, see rollback, pinning and reproducible serving. Rules of thumb for iterating on production models, including the expectation that you will keep launching new ones, appear in Google's guide (Zinkevich, Rules of Machine Learning, Rule 16).