Meridian's crew-scheduling optimization project has access to eighteen months of pilot and cabin-crew assignment history. The data science lead flags that this window barely covers one full seasonal cycle and includes no major weather-disruption events comparable to what the model must eventually handle. From a training-data-requirements standpoint, what should the project manager conclude?

Evaluating training data requirements means checking whether the data represents the range of conditions the model will encounter in production, not just counting months or rows. Eighteen months covering roughly one seasonal cycle with no major disruption events is a real gap for a scheduling model meant to handle weather disruptions and connecting-flight constraints — the model would have no examples to learn from for exactly the scenarios where it matters most. The correct response is practical: extend the historical window if older data exists, supplement with synthetic or scenario-based disruption data, or explicitly scope the initial deployment to steady-state scheduling until disruption data accumulates. Saying eighteen months is simply sufficient ignores the representativeness problem. Claiming CPMAI doesn't require rare-scenario coverage is false — a model that fails exactly when disruption hits is failing at the business-critical moment. And a blanket "never accept less than five years" rule is the opposite error: it's an arbitrary number not grounded in what the specific use case requires; some AI applications work fine with far less history, and CPMAI's Data Understanding phase is about judging sufficiency against the actual business question, not applying a fixed minimum.