PitchAI field tool · v1.0 · July 2026
AI Workflow Proof Checklist
Use this before approving an AI pilot or automation build. A strong candidate has a measurable burden, a real owner, representative data, a review boundary, and a pre-agreed stop rule.
PitchAI CommV · pitchai.net · info@pitchai.net
1. Candidate snapshot
| Workflow in one sentence | |
|---|---|
| Accountable owner | |
| Primary users | |
| Current weekly volume | |
| Current weekly staff hours | |
| Cost of delay or error | |
| One target metric |
2. Pre-build gate
| Gate | Pass when… | Status |
|---|---|---|
| Problem | The pain is a recurring workflow, not a vague request for “an AI strategy.” | ☐ Pass ☐ Gap |
| Owner | One person can define acceptance, make tradeoffs, and attend weekly reviews. | ☐ Pass ☐ Gap |
| Baseline | Current time, quality, cost, backlog, or error rate can be measured. | ☐ Pass ☐ Gap |
| Data | Representative data exists, with permission or a credible sanitized sample. | ☐ Pass ☐ Gap |
| Review | A named human can approve, reject, or correct important outputs. | ☐ Pass ☐ Gap |
| Evidence | Success and failure thresholds are written before the build starts. | ☐ Pass ☐ Gap |
| Alternative | A rule, form, process change, or existing feature has been considered. | ☐ Pass ☐ Gap |
3. Minimum evaluation set
- Normal cases: representative day-to-day inputs and expected outputs.
- Edge cases: missing fields, ambiguous content, unusual formats, or rare combinations.
- Failure cases: unavailable source, invalid response, timeout, model refusal, or corrupt input.
- Permission cases: different roles, restricted records, and attempted overreach.
- Correction cases: a user rejects or edits the output and the system records what happened.
- Cost cases: expected volume, peak volume, reprocessing, and model/API cost guardrails.
- Adoption cases: a real user completes the workflow without the builder coaching every step.
4. Proof ledger
| Question | Evidence to capture | Decision rule |
|---|---|---|
| Does it save meaningful work? | Before/after handling time and manual touches | ________________________ |
| Is the output useful? | Task-specific quality measure and user correction rate | ________________________ |
| Are failures visible? | Error logs, fallback behavior, and escalation path | ________________________ |
| Is control clear? | Approval role, permissions, and audit record | ________________________ |
| Can it be operated? | Owner, monitoring, support, rollback, and monthly cost | ________________________ |
5. Go / redesign / stop
Go
The target metric passes; failures are visible; a human boundary and operating owner exist.
Redesign
Value is credible, but data, workflow, integration, or review design blocks safe rollout.
Stop
The burden is too small, quality is inadequate, risk is uncontrolled, or a simpler option wins.
6. Questions your implementation partner should answer
- Which business metric is this release designed to change?
- What is the riskiest assumption, and how will it be tested first?
- Which outputs require human approval, and who owns that review?
- What happens visibly when data, an API, or the model fails?
- How are permissions, evidence, corrections, and changes logged?
- What is explicitly out of scope for the proof?
- What threshold causes a stop instead of a larger build?
- What will operation, monitoring, model usage, and support cost?
Apply the checklist
One workflow. Two weeks. Measured.
PitchAI's Workflow Proof Sprint turns this checklist into a working slice and a documented go/no-go decision.
Review the proof sprintPrefer to start smaller?Half dayThe team course has an €800 base fee. A written quote confirms the final total, VAT treatment, travel, scope, and cancellation terms.Review the course