The decision standard
An AI proposal is not decision-ready until the organization can name the business outcome, process boundary, accountable owner, current-state comparator, affected people, unacceptable failures, candidate alternatives, and the evidence that will control scale. Technology selection is an output of that work, not the opening assumption.
| Question | Decision artifact |
|---|---|
| What outcome must change? | Metric definition, baseline source, observation period, owner, and consequence of inaction. |
| Where does the process begin and end? | Trigger, endpoint, participants, systems, decisions, handoffs, queues, and exceptions. |
| What causes the current loss? | Evidence-backed constraint and root-cause analysis rather than a generic automation idea. |
| Which alternatives are viable? | Process, policy, rules, integration, search, analytics, conventional automation, machine intelligence, and no action. |
| What is unacceptable? | Critical error, privacy, security, safety, legal, service, financial, and human-oversight limits. |
| What will be tested? | Representative cases, comparator, system boundary, acceptance thresholds, operating cost, and stop conditions. |
| Who decides? | Named process, data, technical, risk, acceptance, and production authorities. |
Task improvement can still damage the process
A tool may accelerate drafting while increasing review time, improve classification while creating a larger exception queue, or retrieve more material while exposing users to stale or unauthorized sources. A credible proposal measures the complete workflow, including downstream work, human correction, failure recovery, and control effort.
Use an intervention hierarchy
- Clarify the policy, ownership, input, or definition that is causing variation.
- Remove unnecessary steps and repair handoffs or system integration.
- Use deterministic rules, search, analytics, or workflow automation where the work is stable.
- Introduce assistive prediction, retrieval, or generation only where variability and judgment justify it.
- Allow bounded actions only after identity, permissions, approvals, verification, budgets, monitoring, and rollback are proven.
A pilot charter is a decision contract
The charter should state the business hypothesis, process population, comparator, primary measure, guardrail measures, human role, system boundary, acceptance threshold, stop conditions, owner, and reversion path. A demonstration that produces plausible output is not enough; the pilot must show that the complete operating system improves the defined result under realistic conditions.
Where this standard does not apply
A low-consequence, reversible personal productivity experiment may not justify the same evidence burden as a production workflow. Evidence should be proportional to consequence. The standard becomes stricter as the system affects people, confidential data, external commitments, money, safety, or difficult-to-reverse actions.
