Method note
Design acceptance before implementation
How a workflow ambition becomes observable tests, refusal behaviour, human release and a bounded implementation decision.
- Question
- What must be decided before an AI-assisted workflow is implemented?
- What was examined
- Workflow boundary, baseline, judgement points, failure behaviour and release ownership.
- Finding
- Acceptance becomes useful when it is observable, bounded and owned before build starts.
- What this cannot conclude
- This method note does not establish an outcome for a customer or prove fit in a specific sector.
A model demonstration can look impressive while leaving the operating decision undefined. Acceptance starts with the workflow, not the demo.
Start with the decision that changes
A workflow has a trigger, an owner, evidence, judgement and a completion state. If a proposed capability changes a consequential decision, the acceptance record should name who remains accountable for that decision.
“The answer looks good” is not an acceptance test. A useful test describes the representative case, expected behaviour, unsupported state and escalation route.
Acceptance is not proof that a model is good. It is a bounded decision that the workflow behaves well enough under named conditions.
Measure before the intervention
Without a baseline, an implementation can demonstrate activity but not improvement. The baseline can be imperfect, but its quality and limitations should remain visible in the decision record.
- Observe current effort, delay, error or risk.
- Record the quality and provenance of the evidence.
- Name changes outside the system that could affect comparison.
- Agree who can accept the result.
Make refusal behaviour part of the test
A system that always produces an answer may be less useful than one that stops well. Unsupported, ambiguous and high-consequence cases need visible routes back to a person.
The test should therefore include expected refusal, escalation and recovery behaviour—not only ideal cases.
Keep the boundary with the result
An accepted result remains specific to the tested workflow, data, users and conditions. It does not establish universal accuracy, performance in another setting or a future service level.
That boundary belongs in the handover record so a later operator can distinguish what was tested from what was merely hoped.