A fire-district aid model receives drift alerts but unstable automatic updates would be dangerous. What retrain policy fits?
Select an answer to reveal the explanation.
Short Explanation
Emergency-aid models are not a good place for surprise auto-updates. Let humans review the drift alert before any retrain goes near dispatch.
Full Explanation
Retraining only after human review of drift alerts for the high-stakes model is correct because fire-district aid updates that are unstable can create safety risk in dispatch-adjacent workflows. Drift alerts should still fire so the signal is not lost, but promotion and retrain execution wait for human review that assesses data quality, evaluation metrics, and operational impact. Human-gated lifecycle policy is the appropriate control when automatic updates would be dangerous.
Auto-promoting every drifted candidate into dispatch without review fails safety and change control. Muting drift alerts during business hours to reduce on-call interruptions fails monitoring purpose because drift in a high-stakes dispatch model can occur, and need review, at any hour, not only outside business hours. Retraining nightly on a fixed schedule regardless of any drift alert fails stability because it decouples retraining from the actual drift signal and still promotes changes into a safety-adjacent system without the human review the high-stakes policy requires.
Exam caveat: high-stakes or safety-adjacent municipal models paired with drift usually want human-gated retrain/promotion—not full automation or alert blindness.
Operational check: keep drift alerts enabled for the fire-district aid model, route them to a review queue with named approvers, require evaluation report sign-off before any endpoint update, and prohibit auto-promote paths on that model’s deployment registry stage.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.