Six months after deployment, Meridian's cargo-and-passenger demand forecasting model starts under-predicting bookings on several routes. Investigation shows fuel-price surcharges and a competitor's new routes have shifted booking patterns since the model was trained. What is this scenario an example of?
Select an answer to reveal the explanation.
Short Explanation
Nothing about the model changed — the world around it did. That's the textbook definition of data drift: the input data's shape shifted (fuel prices, competitor routes) and now yesterday's model is answering yesterday's question.
Full Explanation
Data drift describes exactly this situation: the model's internal logic hasn't changed, but the statistical characteristics of the real-world input data feeding it have shifted — here, fuel-surcharge pricing and a competitor's new routes have changed the booking patterns that once matched the training data. CPMAI's Model Evaluation and Maintenance task explicitly calls for watching for data drift after deployment, because a model trained on yesterday's market conditions will silently degrade as those conditions evolve. Overfitting during Model Development is a different failure mode entirely — it means the model memorized noise in the training set and performs poorly even on fresh, unchanged data from day one; this scenario describes a model that worked fine initially and degraded over time as conditions changed, which is the drift signature, not the overfitting signature. A Go/No-Go failure would have been caught before deployment, but this model was already live and performing well for months, so the original assessment wasn't the problem. A labeling error in training data would typically show up as poor performance from the start, not a gradual decline six months in tied to an external market shift. The exam distinction: drift is about the world changing under a deployed model, and detecting it is a maintenance responsibility, not a one-time development task.