The State Method
Models are useful because they can interpret inputs that do not fit clean rules. That same flexibility should not decide workflow authority. The State Method separates interpretation from state, permissions, validation, approval and recovery, then tests the complete workflow before expanding its scope.
The method applies to one bounded workflow at a time. It produces a decision, not an assumption that every prototype should reach production.
Five states / one decision
Define exactly where the workflow starts, where it ends and who remains responsible for its outcome.
Record the workflow owner, business objective, inputs, outputs, connected systems, current baseline, known exceptions and any consequential action. Exclude adjacent work that cannot be evaluated under the same owner and acceptance criteria.
Output A bounded workflow that can be observed and measured.
Test the workflow on evidence that resembles real operating conditions.
Build representative cases, known failures, ambiguous inputs and edge cases. Compare the proposed behavior with the current baseline. Define decision thresholds before drawing a conclusion. Record uncertainty and abstention rather than treating every output as complete.
Output An evaluation summary that shows what worked, what failed and what remains unknown.
Decide what the model may propose, what software must enforce and what a person must approve.
Define workflow states, input checks, business rules, permissions, tool access and action boundaries. Place approval where a mistake has operational, financial, contractual, safety or reputational consequence.
Output A permission model and explicit approval path.
Make failure visible and recoverable before the workflow can affect real operations.
Identify observable failures and the signal for each one. Specify timeouts, retries, idempotency, safe stops, escalation, manual fallback and recovery. Preserve enough context to reconstruct what happened.
Output A failure register and route back to a valid state.
Use the evidence to choose the next controlled step.
The decision may be to proceed, change the design, gather more evidence, keep the workflow manual or stop. A pilot is justified only when its remaining assumptions can be tested within a bounded scope.
Output A reasoned go/no-go recommendation.
Authority model
The model may extract, classify, summarize, recommend, identify uncertainty or produce a draft. These are proposals inside a defined task.
The surrounding software controls input validation, workflow state, calculations, business rules, permissions, retries, idempotency, logging, approval gates and access to consequential actions.
A named person reviews consequential output, approves or stops the workflow, corrects errors, handles exceptions and decides whether work should proceed. Human approval is an assigned operating responsibility, not a generic “human in the loop” label.
State-transition reference
A workflow should not jump from interpretation to action unless its approved design explicitly allows that action and the consequence warrants it.
Recoverable operation
A retry is not a recovery plan by itself. Repeating a bad request can duplicate an action or hide a persistent fault. Recovery defines which failures may retry, how duplicate work is prevented, what context is retained, when a person is alerted and which safe state receives the case. Some failures should end in manual handling or a stop decision.
The method maps the boundary, tests available evidence, defines controls and produces a go/no-go decision. No production deployment is included.
The method becomes working software in a sandbox or staging environment. Representative cases, real integrations, approvals, logs and recovery behavior are tested against acceptance criteria.
The method governs hardening and operations. Owners, access, monitoring, evaluation cadence, change control, incident response and recovery are defined for the proven scope.
FAQ
No. It is a delivery method for deciding and testing how one AI-assisted workflow should operate. The implementation depends on the workflow and existing systems.
No. Approval should match consequence. Low-consequence, reversible actions may be permitted automatically after validation. Consequential actions need explicit authority and, where required, a named human approver.
Yes. Existing code, evaluations and operating evidence can be reviewed. The next stage depends on what that evidence demonstrates, not on how mature the prototype is described.
The recommendation can be to narrow the workflow, collect better examples, keep the process manual or stop. Avoiding an unsupported build is useful output.
Continue with the evidence
Workflow assessment / first step
Share the current process, expected output, review owner and baseline. Do not send confidential material through the form.