A university's AI strategy names a model to acquire and does not say what any use case should improve. What should the architect do with that document?
Select an answer to reveal the explanation.
Short Explanation
A purchase order that names a truck and not a destination is not a plan. You send this strategy back until each use case states a measurable result the campus can check after a pilot. A model name does not tell you what improved.
Full Explanation
A build strategy is a set of use cases with results someone can check, not a catalog selection. This document names a model and no business outcome, so the architect sends it back until each use case states a measurable result. Approving it because a named model is enough to start funding use cases across the campus releases money with no way to tell a successful pilot from a deployed demo. Adding a list of tool names under the model and sending the document on for budget approval lengthens the shopping list and still has no result. Choosing a landing zone for the named model and treating that choice as the missing outcome confuses where the model runs with what the university will measure. Exam caveat: the result belongs on the use case, and several use cases may share one model. Naming the model once does not fill those result lines. Operational check: return the document unless every use case has a result you could compare before and after the pilot, such as time saved on a named task or a quality bar the faculty already uses in that office.