Meridian Regional Airlines' data science team reports that their predictive-maintenance model hits 96% accuracy on held-out sensor data. Before the AI project manager signs off on the CPMAI Model Evaluation phase, what should the evaluation plan check first?
Select an answer to reveal the explanation.
Short Explanation
A shiny accuracy number means nothing on its own — CPMAI ties Model Evaluation back to the business question you wrote down at the very start. If 96% accurate still misses the maintenance-scheduling target you set in Business Understanding, it's not done, it's just precise.
Full Explanation
CPMAI's Model Evaluation task exists to answer a business question, not to admire a technical metric in isolation. The evaluation criteria and plan must be formulated against the acceptable performance metrics established back in the Business Understanding phase — for Meridian, that likely means measurable reductions in unscheduled groundings or maintenance delays, not just raw model accuracy. The correct option ties evaluation directly to that earlier business anchor. Comparing to last quarter's accuracy is a useful trend line but not a substitute for checking against the original business target — a model can improve version-over-version and still fall short of what the business actually needs. Passing a standard software unit-test suite verifies code correctness, not model performance against real-world maintenance outcomes; that's an engineering gate, not an evaluation-phase gate. Using the newest architecture is a model-development choice, and CPMAI is explicitly vendor- and technique-agnostic — architecture novelty is never itself an evaluation criterion. The exam-relevant takeaway: every Model Evaluation activity should be traceable to a metric someone wrote down during Business Understanding, closing the loop CPMAI is built around.