Start with the decision.Then choose the intelligence.

A model is a component, not an outcome

Teams often begin an AI initiative by selecting a model or naming a technical capability. That makes the conversation concrete, but it can leave the operating purpose unresolved. A useful starting point is the decision that needs to become faster, more consistent, or better informed.

The decision frame changes the design brief. It identifies who acts, what they need to know, what happens after a recommendation, and which consequences require a human to retain control. Only then can the team judge whether rules, analytics, machine learning, generative AI, or a simpler workflow change is the right intervention.

Write the decision contract

A decision contract is a short, shared description of the operating moment the system will support. It should be understandable to the people who own the process and specific enough for a delivery team to test.

• Name the decision, its frequency, and the person accountable for it.
• List the minimum evidence required before an action is appropriate.
• Define what the system may recommend, automate, or only observe.
• Specify escalation paths, exceptions, and the record that must remain.
• Agree on the operating signal that would show the decision is improving.

Let the architecture follow the responsibility

Once decision rights are explicit, architecture choices become easier to compare. Retrieval may be required when answers need grounded source material. A rules service may be preferable when policy must remain deterministic. A human review queue may matter more than another round of model tuning.

This sequence also creates a more honest portfolio. Initiatives can be prioritized by operating value, feasibility, risk, and readiness instead of novelty. Some ideas will advance to prototypes; others will become data, process, or policy work. Both are useful outcomes of disciplined framing.