A public-health risk model must not reach production until a designated reviewer explicitly approves the newest trained version. The team wants this approval to be the actual gate that controls deployment, not just a policy people are expected to follow. Which mechanism enforces this?
Select an answer to reveal the explanation.
Short Explanation
A written policy nobody has to actually satisfy is more of a suggestion than a gate — like a sign that says "employees must wash hands" with no one checking. Wiring the pipeline to require a model registry approval status before it will promote a version turns that expectation into an actual mechanical checkpoint: no approval, no deployment, regardless of what anyone remembers to do.
Full Explanation
A model registry tracks versioned model packages along with an approval status field, and when the deployment pipeline is configured to check that status before promoting a version, the approval becomes a mechanical gate the pipeline itself enforces rather than a step someone has to remember. A written runbook documents intent, but it has no way to stop a pipeline run from proceeding if a person skips the check, whether by oversight or under time pressure. Granting the reviewer deploy permissions directly conflates review authority with deployment execution and removes the pipeline from the loop entirely — nothing then confirms that a deployment that happens was actually preceded by a genuine review. A code comment is documentation with no enforcement power whatsoever; nothing reads it or acts on it automatically, so it provides no actual control over what gets deployed. Scope caveat: the pipeline should also confirm the specific model version being deployed matches the one that received approval, since approving one version doesn't implicitly approve a different version built afterward. Operational check: attempt to promote an unapproved model version through the pipeline and confirm it is blocked before reaching production.