After the FAA updates duty-time regulations, Meridian's crew-and-gate scheduling optimization model — unchanged since deployment — begins producing schedules that violate the new rules, even though it never violated the old ones. What CPMAI concept does this best illustrate?
Select an answer to reveal the explanation.
Short Explanation
The model didn't get worse — the rulebook it was scheduling against changed. New FAA duty-time rules are exactly the kind of external shift that counts as data drift: same model, different world.
Full Explanation
This scenario is a clean example of data drift: an external change to the regulatory environment — new FAA duty-time rules — altered what counts as a valid scheduling input/constraint, so the model, unchanged since deployment, is now operating against a reality that no longer matches what it was trained on. CPMAI's Model Evaluation and Maintenance task calls for exactly this kind of ongoing vigilance for data drift after deployment. Calling this model drift mischaracterizes the cause — model drift describes the model's learned input-output relationship going stale even when inputs are unchanged; here, the constraint environment (the 'inputs' in a broad sense, the rules the schedule must satisfy) is what changed, which is the data drift signature. Overfitting is a Model Development-time defect present from the start — a model too closely fit to its original training set that performs poorly even on fresh, unchanged data; it doesn't explain a model that worked fine under the old rules and only failed after an external regulatory change. Blaming the original Model Evaluation Go/No-Go is unfair and inaccurate — that assessment correctly validated the model against the rules that existed at the time; no evaluation process can be expected to anticipate a future regulatory change. The exam point: a regulatory or environmental shift after deployment is a canonical data-drift trigger a PM should recognize and plan monitoring for.