An innovation office uses a decision tree: commodity GenAI → buy; unique parcel logic → build; research computer vision → partner. What practice is this?
Select an answer to reveal the explanation.
Short Explanation
Different jobs, different doors: you buy the commodity, build the unique parcel logic, and partner on research computer vision. You’re using a sourcing framework to match each use case to the right approach.
Full Explanation
A structured sourcing framework maps use-case characteristics to build, buy, or partner choices, keeping municipal decisions consistent. Commodity GenAI for routine drafting or FAQ patterns often fits buy. Unique parcel logic tied to local ordinances and GIS semantics often fits build because differentiation and control matter. Research-grade computer vision may fit partner when the city needs specialized expertise without creating a permanent research lab. Applying a structured framework by use-case type is the practice shown: criteria first, sourcing model second. Selecting every project as a custom build with no analysis fails by ignoring commodity options and inflating cost and sustainment burden. Letting the loudest lobbyist choose the sourcing model fails governance and can produce inconsistent, vendor-captured portfolios. Choosing municipal AI vendors solely by lowest upfront cost, without evaluating use-case sourcing fit, ignores whether buying, building, or partnering suits the work and can undermine long-term value. Exam caveat: decision trees should be living guidance, with escape hatches for hybrid patterns such as buying a model and partnering on integration, and for risk overrides when data sensitivity blocks an otherwise suitable commodity buy. Operational check: for each new civic AI proposal, record the framework branch applied, the evidence supporting it, and any justified exceptions so the portfolio board can review consistency over time.