Meridian Line wants to promote model versions to production only after they beat the current production version on the evaluation suite, using a repeatable pattern where the currently-trusted version and a candidate both have stable names the deployment pipeline can reference. Which pattern fits?

A champion/challenger pattern uses Unity Catalog model aliases as stable, semantically meaningful references: 'champion' always points at whatever version is currently trusted in production, and 'challenger' points at a candidate under evaluation. Promotion is simply moving the 'champion' alias to reference the challenger's version once it passes evaluation, and the deployment pipeline, application code, and serving configuration never need to change since they always ask for 'champion' or 'challenger' by name. This is exactly the repeatable, stable-name pattern the scenario asks for. Deleting the current production version on every new candidate is destructive, removes rollback capability, and is not how staged promotion is meant to work — it also risks an outage if the new candidate fails evaluation after the old version is already gone. Renaming the schema per candidate churns the model's governed namespace for no benefit and would break any reference relying on a stable catalog.schema.model path. Hardcoding version numbers into every calling application and updating them manually on each promotion is exactly the maintenance burden aliases exist to eliminate — it does not scale and invites drift between what different callers reference. For the exam, know champion/challenger as a named application of the alias mechanism for exactly this promotion workflow.