Meridian's demand-forecasting model outputs a specific number of passengers expected on a route next month (prediction), a data scientist explains why the model believes fuel-price trends are driving that number (inference), and a separate check confirms the model performs well on routes it has never seen historical data for (generalization). Why does the PM need to keep these three concepts distinct when evaluating the project?

CPMAI Task 3 requires distinguishing between prediction, inference, and generalization as related but separate model capabilities, and this scenario is designed to show why collapsing them into one evaluation is risky. Prediction is the model producing a specific forecast; inference is explaining or reasoning about what is driving that outcome; generalization is the model's ability to perform well on new situations (a route with no historical data) that differ from its training data. A model can be strong at one and weak at another — for instance, a model with good prediction accuracy on familiar routes might generalize poorly to a brand-new route Meridian is about to launch, which is precisely the scenario where forecasting matters most for a new-market decision. The 'three names for the same metric, testing one suffices' distractor would let a real generalization failure slip through undetected if the PM only checked prediction accuracy on familiar data. The 'generalization is about UI across devices' distractor completely misdefines a core machine-learning evaluation concept as a front-end/UX detail. The 'inference is only relevant to reinforcement learning' distractor is wrong — inference, in this sense, is a general model-reasoning/explanation concept applicable across supervised forecasting models too, not exclusive to reinforcement learning. Testing all three separately is what protects Meridian from a model that looks good on paper but fails on the new routes leadership cares most about.