ML Governance: The Champion-Challenger Pattern for Model Deployment
Your ML serving code should never know version numbers. The champion-challenger pattern with MLflow aliases gives instant rollback.
Your ML serving code should never know about version numbers. Ever.
If your inference service loads fraud-detector-v47, you have a problem. What happens when v48 is ready? Code change. New deploy. Downtime risk.
Now imagine this: your service always loads the model tagged @champion. (MLflow Model Registry docs) When v48 is promoted, the tag moves. Next request gets the new model. Zero code changes. Zero downtime.
The Champion-Challenger Pattern
| Role | Alias | Purpose |
|---|---|---|
| Champion | @champion | Currently serving production traffic |
| Challenger | @candidate | Being evaluated against the champion |
The flow:
- Train a new model
- Register it as
@candidate(see MLflow lifecycle for how aliases work) - Evaluate both on the same test set (fair comparison)
- Candidate wins? Move
@championto the new version - Candidate loses? Discard. Production never notices.
The Quality Gate
Not every model that finishes training deserves to enter the registry.
Two-threshold gate:
- Net Benefit (dollars saved) must exceed $40,000
- F1 score must exceed 0.20 (performance floor)
If either fails, the model stays in the experiment tracker. It never reaches the registry. It never gets near production.
40% of candidates get rejected at this gate. That’s not failure. That’s the system working.
The DevOps Parallel
Blue-green deployment: Blue is live. Green is the candidate. Test green. If it passes, swap traffic. If it fails, blue stays live.
Model registry aliases work the same way. @champion is blue. @candidate is green. The swap is instant. Just move the alias.
Rollback? Move @champion back to the previous version. One API call. Done in seconds.
This is Part 16 of the MLOps for DevOps Engineers series. For weekly updates, join the newsletter.