An AI proof of concept is a bounded test of whether one defined workflow can produce a useful result under stated constraints. It should leave evidence a reviewer can inspect: the input set, expected output, human decisions, failures, costs, and the reason to continue or stop. A convincing demonstration is not permission to deploy it.
This guide concerns business-operations workflows such as support triage, document intake, lead research, and executive briefing preparation. It is not a general test of whether a model can answer questions, and it is not a software-testing or factory-automation guide.
PoC first, limited pilot second
A PoC tests the workflow shape with safe inputs, controlled tools, and disabled or sandboxed consequential actions. A limited pilot tests the same boundary in a small real operating lane with named reviewers, monitoring, and a rollback or stop path.
Do not blur the two. A successful PoC earns the right to plan a pilot. It does not quietly become production because the demo endpoint happens to work.
A PoC should end with a decision, not applause
The final packet should support one of four decisions: expand, revise, keep advisory, or stop.
- Expand: the boundary held, the artifact helped, the exceptions were manageable, and ownership is clear enough to plan a limited pilot.
- Revise: the use case still matters, but the sources, field map, review packet, routing, or access boundary needs work.
- Keep advisory: the system may prepare internal material, but it should not trigger an external or record-changing action.
- Stop: the workflow is too rare, ambiguous, sensitive, difficult to review, or weak economically to justify maintenance.
If the evidence cannot support one of those decisions, the PoC did not prove enough.
Copy this one-page AI PoC packet
The packet is deliberately ungated. Copy it into a working document and replace every prompt with evidence from one workflow.
Workflow and decision to be tested:
Current baseline and unit of work:
Approved sources and source versions:
Input fixtures and expected reviewer decisions:
Output artifact and required fields:
Reviewer and approval boundary:
Actions disabled during the PoC:
Failure, privacy, and recovery cases:
Timebox and spend limit (set by owner):
Operating cost observations:
Unresolved risks:
Verdict: expand / revise / keep advisory / stop
Evidence supporting that verdict:
Pilot prerequisites, if applicable:Set the timebox and spend limit for the actual owner, risk, and workflow. There is no useful universal PoC duration or budget. The limit exists to stop an uncertain test from turning into an open-ended implementation project.
Track operating cost as well as build cost: reviewer time, exception handling, retries, source maintenance, provider use, and the work needed to keep the test set current. Use the automation ROI guide when the next decision needs a cash-versus-capacity model rather than a vague savings estimate.
Filled example: support-triage PoC packet
Fictional planning example. This packet uses safe fixtures to show what should be tested. It does not report a customer implementation, and none of the cases below has been run.
Workflow and decision to be tested:
Prepare a support-triage queue item and bounded reply draft so a support lead
can decide whether the preparation step is useful enough for a limited pilot.
Current baseline and unit of work:
One inbound request. Current handling steps and review time still need to be
observed before any economic claim.
Approved sources and source versions:
Synthetic request fixtures, an example approved support policy with a recorded
version, and a synthetic account-status fixture.
Output artifact and required fields:
Stable request ID; category and reason; urgency and risk; source version;
missing facts; held draft; escalation owner; proposed action; reviewer decision;
artifact revision; execution status.
Reviewer and approval boundary:
A support lead may approve, correct, reject, or escalate the exact queue-item
revision. A prior decision does not authorize a changed draft.
Actions disabled during the PoC:
Customer send, refund, credit, cancellation, account edit, payment-state change,
and autonomous ticket closure.
Failure, privacy, and recovery cases:
Missing identity, refund request, conflicting policy, changed draft, unavailable
tool, retry, and duplicate prevention.
Timebox and spend limit (set by owner):
Pending owner decision. Do not substitute a generic duration or budget.
Operating cost observations:
Record reviewer time, corrections, exception handling, retries, provider use,
and source-maintenance work. No cost result exists before the fixtures run.
Unresolved risks:
Identity verification path, policy ownership, duplicate detection, retention,
and the operating burden of escalations.
Verdict:
Not available before the test set runs.
Evidence supporting that verdict:
Not available.
Pilot prerequisites, if applicable:
Named owner, approved source set, accepted artifact fields, repeatable review
state, visible failures, duplicate controls, and a rollback or stop path.The companion synthetic support-triage review queue shows the artifact shape in more detail. It is a convenient existing example, not evidence that support traffic or customer demand selected this use case.
Fixture record: keep expected behavior separate from evidence
For every fixture, record the expected reviewer decision before the run. Record the actual artifact, reviewer decision, correction, failure, and recovery only after the run. Expected behavior is not an observed result.
- ST-01 — normal draft case
- Expected reviewer decision: inspect the cited policy, correct if needed, and approve only the exact held draft revision.
- Observed result: not run.
- ST-02 — missing-identity case
- Expected reviewer decision: request an approved identifier through the authorized channel; do not infer an account.
- Observed result: not run.
- ST-03 — refund case
- Expected reviewer decision: escalate to the authorized human; no refund, credit, payment change, or promise.
- Observed result: not run.
- ST-04 — conflicting-policy case
- Expected reviewer decision: stop pending source resolution; expose the conflicting versions.
- Observed result: not run.
- ST-05 — changed-draft case
- Expected reviewer decision: invalidate the prior approval and return the revised artifact to review.
- Observed result: not run.
- ST-06 — tool-failure/retry case
- Expected reviewer decision: show the failure, check whether an action already occurred, and block a duplicate before any sandbox retry.
- Observed result: not run.
A real run record should add timestamps, source versions, artifact revisions, corrections, retry identifiers, and the reviewer who made each decision. Leaving results as not run is more useful than manufacturing a neat pass rate.
The six proof components
The copyable packet is the summary. The six components below define the evidence behind it.
1. A one-workflow contract
Write the workflow boundary before choosing tools. Record the trigger, approved sources, artifact, reviewer, proposed post-approval action, stop cases, and systems that remain out of scope.
“Improve support with AI” is not a workflow contract. “Prepare a support-triage note and reply draft from the ticket, account record, and approved policy; route refund, legal, access-change, and conflicting-policy cases to the support lead; do not send or mutate the account” is testable.
The contract keeps the PoC from becoming a pile of adjacent features whenever the first example looks good.
2. A fixed test set
Choose the examples before tuning the workflow. Otherwise every failed run becomes an excuse to swap in an easier case.
Include:
- normal cases that represent the ordinary path;
- edge cases with unusual but valid inputs;
- failure cases with missing fields, conflicting facts, unsupported formats, or unavailable tools;
- privacy or access cases the workflow must reject or narrow;
- recovery cases that test retry, correction, and duplicate prevention.
Use sanitized examples or safe fixtures. Preserve the expected reviewer decision for each one: prepare, approve, correct, escalate, reject, or stop. A small fixed set is not a benchmark; it exists to expose the known failure surface.
3. A reviewable artifact
The PoC should produce a durable work object, not a transient chat answer. That artifact might be a cited research brief, an extraction row with source warnings, a support queue item, an executive briefing, or a content brief with claim sources and approval flags.
The reviewer should see what the system used, what it prepared, what remains uncertain, and what would happen after approval. A confidence label without the underlying evidence is decoration.
4. A human authority and execution map
For every case, show:
- what the system may prepare;
- who may approve, correct, reject, or escalate it;
- which exact artifact revision the decision applies to;
- what action would run after approval;
- what remains disabled during the PoC.
A support-reply PoC can prepare a draft without sending it. A CRM-cleanup PoC can propose field changes without writing them. A document-intake PoC can populate a review queue without updating the authoritative record.
If a consequential field changes after review, the prior approval is stale. The item must return to review. “A human approved something earlier” is not an execution rule.
5. A run record that exposes failure
Keep a record for each fixture: source set and dates, artifact revision, validation and exception flags, reviewer decision, correction note, proposed action, execution status, failure and recovery result, and unresolved questions.
This makes disagreement useful. A rejected draft may expose a prompt problem, a retrieval rule, a field map, a stale policy, a weak interface, or a workflow boundary that should be narrower.
The model name is not the evidence. Neither is a screenshot of the best answer. The evidence is the fixed test set, artifacts, reviewer decisions, failures, corrections, and resulting verdict.
6. A maintenance verdict
A technically successful demo can still be a bad operating investment. Identify who would own source changes, prompts and rules, field mappings, the regression set, review-queue quality, provider changes, retries, duplicate prevention, privacy, retention, and the decision to pause or retire the workflow.
Then ask the ugly question: does the artifact remove useful preparation work, or merely move it into checking vague prose? A PoC that nobody can own should stay a disposable demo.
Use a proof scorecard
Review the packet with the people who own the workflow.
| Proof question | Evidence to inspect | Decision signal |
|---|---|---|
| Did the workflow stay inside scope? | Contract and run record | Scope held, drifted, or was too broad |
| Did it handle representative work? | Fixed test set and case results | Normal and difficult cases were visible |
| Was the output worth reviewing? | Artifacts and reviewer notes | Useful, correctable, noisy, or unusable |
| Did human authority remain real? | Approval and execution map | Reviewer could change or stop the outcome |
| Were failures legible and recoverable? | Error, correction, retry, and duplicate tests | Failure was visible and created no silent action |
| Can someone maintain it? | Owner and maintenance verdict | Named owner, repair path, and stop rule exist |
Do not turn those rows into an invented composite score. Each should carry its evidence, unresolved risk, and next decision.
What does not count as proof
Treat these as demo material, not operational evidence:
- one successful run on a hand-picked input;
- a chat transcript with no source trail;
- a vendor benchmark unrelated to the workflow;
- the system grading its own output without a human reference;
- an integration diagram with no failed-run path;
- a reviewer who cannot see the proposed action;
- a “human in the loop” label with no durable approval state;
- a prototype that depends on one builder repairing every run;
- a savings estimate with no observed baseline or maintenance cost.
These may explain an idea. They do not justify connecting more data, authority, or production systems.
Choose the next step from the evidence
If the workflow contract is still vague, start with a workflow audit. The useful output is the map, test set, authority boundary, and no-go risks.
If the boundary is clear but the examples, access path, reviewer, or stop conditions are missing, complete the sprint input packet first.
If the packet is complete, an operations sprint can build one artifact and one review path. The first PoC still needs permission to stop. Killing a weak automation idea before it reaches production is useful proof too.