A model registry deployment approvals workflow is the set of controls that decide which registered model version is allowed to receive production traffic, and only three mechanisms in mainstream platforms actually enforce that decision: MLflow deprecated its fixed registry stages in version 2.9.0 and replaced them with aliases and tags, SageMaker gates deployment behind an explicit approval status on the model package, and Azure Machine Learning pins deployment settings through registry-scoped templates. If your registry is only a folder of artifacts that a human renames before shipping, none of these gates is active, and promotion is effectively a convention that any pipeline step can violate. The difference between the two setups is the difference between an audit trail and a wish.

What an Approval Must Gate

An approval that does not control the serving path is decoration. The gate has to sit on the exact artifact reference that the inference infrastructure resolves at deploy time: the alias the serving job loads, the model package the EventBridge rule reacts to, or the registry asset the endpoint deployment pins. Anything downstream of that resolution, such as a Jira ticket, a Slack message, or a checkbox in a release notes document, can be bypassed by whoever holds deploy credentials. Anything upstream, such as a merge check on the training code, approves code and not the trained weights, so it cannot catch a model that regressed for data reasons while the code stayed clean.

In practice the approval needs to answer three questions with evidence attached: who approved this exact version, against which evaluation results, and where that version is now serving. A registry that cannot answer all three questions in one query will not survive an incident review, because during an incident you need to know within minutes which approved version is live and what it was approved against.

How Each Registry Enforces It

The three major registries enforce approvals differently, and the enforcement strength varies more than most teams assume when they pick a platform.

On AWS the control is unusually crisp: moving a version from PendingManualApproval to Approved is the event that triggers the project CI/CD pipeline to deploy it, and the reverse transition to Rejected triggers a redeploy of the latest still-approved version. The approval state is a first-class field on the model package, not a tag someone typed, so tooling can rely on it. On Azure, the platform does not block a deployment that overrides with a template outside the curated list, which means the allowed_deployment_templates field on a model is guidance for consumers rather than a hard boundary; the enforced parts are the registry scoping and the version pinning. On MLflow the recommended pattern is environment-shaped registered models with authentication-based permissions, for example a prod-prefixed model that only the release role can write to.

For alias-based serving, assign a champion alias to the version serving production traffic and a challenger alias to the candidate under evaluation, so rollout becomes an atomic alias move rather than a redeploy of modified code. Because more than one alias can point at a version, this also gives you a cheap way to run a shadow comparison before promotion.

Wiring the Approval Pipeline

The reliable sequence, regardless of platform, keeps evaluation, approval, and traffic shift as separate, observable steps:

1. Register the trained version with a pending status, never directly into a serving-targeted name or alias.
2. Run the offline evaluation suite and write results as metadata on the version, keyed by run and dataset hash.
3. Route the version to a reviewer who can compare it against the currently approved version on the same metrics, not in isolation.
4. On approval, mutate the single platform primitive that serving resolves: approval status, alias, or pinned template reference.
5. Shift a small traffic slice, watch latency and error budget alongside model metrics, then complete the shift or roll the alias back.

Step 4 is the only step that should require elevated permissions, which is what makes the approval meaningful. Treat the eval harness the same way you treat CI for code: an approval without an evaluation gate attached is a rubber stamp with an audit log. Teams that already run LLM evaluation pipelines in CI have the harness half built, since the same result artifacts can back registry approvals; the pipeline patterns are covered in our LLM evaluation pipeline setup and the capacity planning half lives with GPU node pool scheduling.

Failure Modes Worth Checking

Most broken approval flows fail in one of four ways. Check your setup against this list quarterly:

• Alias drift: the serving job pins a version number instead of an alias, so approvals change nothing that production reads.
• Self-approval: the same role that trains the model can flip its approval status; separate the write scopes.
• Evaluation orphaning: approval metadata references a dashboard, not an immutable result set, so the evidence decays.
• Rollback amnesia: nobody archived the previously approved version, so a rejection cannot restore service quickly.

None of these show up in a demo, and all of them show up during an incident. The registry permissions question connects to the same least-privilege work discussed in locking down AI agent tool permissions in the cloud, because a deploy credential that can bypass approval is just another overprivileged tool. Wire the gate to the primitive that serving actually resolves, keep the approval permission separate from training, and the registry becomes the control point it was meant to be.

Sources

• MLflow Model Registry Workflows
• AWS SageMaker: Update the Approval Status of a Model
• Microsoft Learn: What are deployment templates in Azure Machine Learning