Model Promotion

Model promotion authorizes a specific evaluated candidate for a production role. Preserve its artifact identity and evaluation evidence. Deployment can create resources or apply configuration, but replacing the candidate with an unverified retraining or rebuild breaks the connection to those checks.

MLflow distinguishes registered versions from mutable aliases that select a version at lookup time. Changing an alias does not necessarily update a service that already loaded its model. Deployment or reload logic must apply the selection, and traffic and runtime checks must confirm what is actually serving. Model Registry explains the distinction between registry state and an inference process.

Five checks before authorizing production use

1. Input checks meet the agreed contract. Bind schema, distribution, completeness, label, and time-availability checks to the actual run and data versions. Passing provides evidence within those checks’ coverage; it does not prove that every record is correct. Required failures must block promotion.
2. The candidate meets the stated objective. Google Cloud’s MLOps guidance uses comparison with a baseline as a validation step. Include the incumbent where relevant, and define practical improvement or a noninferiority limit before inspecting final results. Similar predictive quality may be acceptable when the approved objective is lower latency or cost. Use comparable evaluation conditions and appropriate uncertainty methods; paired comparison on shared cases is useful but not the only valid design.
3. Important slices meet predefined limits. State permitted deterioration, uncertainty, and decision criteria in the evaluation protocol. A small observed decrease is not automatically a meaningful regression, and an aggregate gain can hide a consequential subgroup loss.
4. The decision rule is validated with the candidate. Recheck the decision threshold under the intended costs and constraints, and retain its version with the release. The same threshold may remain appropriate. Tune changes on development data before evaluating the fixed candidate and rule on the final set.
5. The required authority approves the transition. Require a separate human reviewer where policy demands one. Where an approved policy permits automatic promotion, enforce its scope and protect rules, evidence, credentials, and bypass paths from unilateral alteration. Separation of Duties explains the difference; a second account alone does not establish independence.

Designing for reversal

Define recovery time and a fallback appropriate to the service’s risk. Retain the earlier artifact, fitted preprocessing, runtime, decision rule, and compatible feature versions. Changing a feature does not invalidate the fallback if the old path remains available; silently replacing its inputs can. A previous-model pointer, as recommended by Google Cloud’s guidance, helps locate the candidate but does not execute recovery. Apply the deployment or reload, confirm responding versions and traffic, and distinguish restored service from undoing decisions already made. Provide a way to stop further harmful actions during recovery.

A shadow run observes candidate outputs without acting on them. A canary limits exposure to real decisions and can reveal problems before a wider rollout. Both need explicit pass, stop, and recovery criteria; neither removes the need for rollback planning or proves every failure will be caught. Environment Promotion discusses the corresponding artifact and environment controls.

What the record should say

Record the approved candidate and prior version, exact artifacts and configuration, evaluation data and results, decision rules, approval identity or automatic-policy version, and the deployment or reload outcome. Record which runtime versions actually received traffic. Intended use and limitations belong in the model card. An alias change records a selection change; by itself it establishes neither the time traffic changed nor why production use was authorized.

Failures to watch for include substituting an unverified retraining for the tested candidate, comparing results without a common estimand or suitable inference, omitting the decision rule, and retaining no usable recovery path. Repeated comparisons also need a plan that protects final evaluation from selection feedback. Nobody Could Rebuild Version 14 places promotion within the wider lifecycle.

References:

• Google Cloud Architecture Center, MLOps: Continuous delivery and automation pipelines in machine learning (Creative Commons Attribution 4.0) — model validation against a baseline and keeping a pointer for rollback.
• MLflow documentation, MLflow Model Registry — model aliases, cited as one widely used implementation rather than as a recommendation.
• MLflow documentation, Model Registry Workflows — resolving and loading aliases.