Discovery Intake as a Decision Contract
Understand how to translate AI project requests into formal decision contracts that specify the supported decision, workflow boundaries, measurable KPIs, and a detailed measurement plan. This lesson guides you to establish accountable and auditable decision criteria that align stakeholders and prevent assumption-driven disagreements during AI system design.
Before discussing architecture, discovery should establish a decision contract. This includes a named decision, a workflow boundary, a baseline, target KPIs, and a measurement plan, all agreed upon by the stakeholders responsible for evaluating the outcome. Without this agreement, later disagreements about models, retrieval, or agents can trace back to requirements that were never documented.
Consider how this applies to the copilot example. We want an internal copilot for employees who handle customer cases. The initial request is straightforward: help staff find the applicable internal policy and draft the case note that documents their actions in an environment where relevant actions must be auditable. That request might reach the architect as: “Draft a copilot that answers policy questions and helps staff write compliant case notes.” This request does not define the decision the project is meant to support. It also does not define boundaries around regulated actions, establish a baseline, or specify how success will be measured. Discovery should convert that request into measurable requirements and decision criteria while deferring data design and model selection to later chapters.
The ...