Meridian's data science team has finished building a predictive-maintenance model that forecasts engine bearing wear from sensor data, and wants to move straight to production. The program manager insists on a formal quality assurance step first. What should that QA step center on?
Select an answer to reveal the explanation.
Short Explanation
Think of QA the way a mechanic road-tests a repaired engine before it flies revenue passengers — you don't trust the shop's word, you run it on data it hasn't seen. A model that only shines on the exact aircraft it trained on hasn't proven anything about the rest of the fleet.
Full Explanation
Quality assurance for an AI model is fundamentally about evidence of generalization, not just a demo that works on familiar data. Holding out a validation set the model never trained on, then measuring performance against it, is the standard mechanism CPMAI expects a PM to insist on before sign-off — it directly tests whether the bearing-wear model learned real patterns or simply memorized the training aircraft's sensor history. Deploying first and watching dashboards is monitoring, which matters later, but it substitutes production passengers' safety margin for the validation step that should have happened first — that's QA-after-the-fact, not QA. Union sign-off on architecture is a stakeholder-consultation step relevant to scheduling or maintenance sign-off tools generally, but it is not a technical quality assurance mechanism and mechanics are not evaluating model internals. Trusting another airline's published benchmark ignores that model performance is fleet- and data-specific; a bearing-wear model tuned on one carrier's sensor data and maintenance logs will not carry that accuracy claim to Meridian's own aircraft without independent validation. The exam-worthy distinction is validation-data testing versus any of these process substitutes.