A transit maintenance-prediction model's accuracy is checked periodically against the baseline recorded at deployment time, with alerts triggered when accuracy falls below an agreed threshold. What monitoring practice does this describe?
Select an answer to reveal the explanation.
Short Explanation
Recording a baseline the day a model launches and then checking against it over and over is exactly what performance-baseline monitoring means. It's less a one-time gate and more an ongoing habit, like a doctor tracking your vitals against your own baseline visit, not some population average. Alerting when it slips below an agreed threshold turns that baseline into an actual early-warning system.
Full Explanation
This describes performance-baseline monitoring: a reference accuracy figure is captured once at deployment, and every subsequent check compares current performance against that fixed reference point, with an alert firing once the gap crosses an agreed threshold, the mechanism for catching degradation over the model's operational life. A one-time acceptance test happens before deployment and is never repeated, so it establishes readiness but can't detect anything that happens afterward, the opposite of the ongoing, periodic checking described here. A cost dashboard tracks infrastructure spend, which has no bearing on whether the model's predictions are still accurate; a model can get cheaper to run while quietly getting worse at its job. An access-control review confirms who is authorized to call the endpoint, a security control unrelated to prediction quality. Scope caveat: a baseline set once at deployment can itself become stale if the underlying maintenance patterns genuinely shift over time, so periodic baseline recalibration should be considered alongside the alerting. A concrete operational check: confirm the alert threshold was set based on an analysis of acceptable accuracy variance, not an arbitrary round number.