Test the assumption that can stop delivery

Learning objective

Frame a proof-of-value hypothesis and a proof of concept that tests the riskiest assumptions before committing to a production design.

Core idea

A proof of concept tests whether a mechanism can work under relevant constraints. A proof-of-value hypothesis connects that mechanism to an improvement somebody needs. You need both: a correct summary may save no time, and a promised time saving may depend on extraction quality you have never measured.

Write the hypothesis before running the experiment. State the user, capability, baseline, target, constraints, and observation that would defeat the proposal. Then test the assumption most likely to invalidate the design. A polished end-to-end demonstration can leave that assumption untouched.

Anthropic’s evaluation guidance starts with specific, measurable, achievable, and relevant success criteria and asks for tests that mirror the real task distribution, including edge cases. Its agent guidance recommends starting with the simplest solution. Together they support a small experiment with a meaningful failure condition instead of premature production architecture.

How it works

Make the hypothesis falsifiable

Translate the accepted scope from 1.1.1 and the acceptance contract from 1.1.2 into a short decision statement. Specify which capability should change which business measure. State what stays outside the experiment and which costs count toward value.

A useful hypothesis says, for example, that document-based drafting reduces reviewer handling time on an eligible class of cases while meeting a defined factuality rubric and a per-case processing budget. The business improvement depends on reviewers actually using the draft, not merely on Claude producing one. Treat model quality and workflow value as separate assumptions.

Record the baseline with its measurement method. Comparing model processing time with human handling time mixes unlike quantities. Compare the existing complete workflow with the candidate complete workflow, including correction, review, and unresolved cases. If a capability helps only one case class, state that eligibility rather than extrapolating to every incoming request.

The hypothesis artifact should also name a stop or reshape condition. Set it in advance so the result can change the decision. If every outcome leads to implementation, the experiment is an approval ritual rather than a test.

Rank assumptions by their effect on the design

List the assumptions that must hold: authorized evidence is available, the input is readable, outputs meet the domain rubric, reviewers can use them, and the selected delivery surface satisfies the required boundary. Mark which assumption would invalidate the proposal and which would merely change a parameter.

Test the invalidating assumption first. If staff cannot obtain the documents they need, building a dashboard does not answer that question. If the documents exist but contain contradictory instructions, test interpretation before spending effort on deployment automation. Anthropic’s recommendation to prefer simple designs keeps that first test from becoming an unnecessary agent project.

Do not assume a larger model, more tools, or an autonomous loop resolves every failure. An experiment can reveal an inadequate input source or an unsuitable task allocation. The useful outcome might be a narrower workflow, a better intake process, or retaining the existing human approach.

Use evidence that resembles the work

Use authorized historical cases with a defined reference answer or expert rubric. Anthropic’s guidance calls for task-specific evaluations that reflect real-world distribution and include ambiguous, irrelevant, and other challenging inputs. Sample across the channels and case classes that could change the decision, rather than selecting only clean documents.

Separate examples used to revise the prompt from the held-out cases used to judge the hypothesis. Label expected outputs before using model responses to influence the decision. Otherwise the experiment can reward agreement with the candidate rather than correctness against the business task.

Choose the scoring method by the criterion. Anthropic documents code-based, human, and LLM-based grading. Code can check an exact field against a reference. A domain rubric can require an expert to judge whether a summary omits a material fact. LLM grading can increase throughput, but a promising score still needs to answer the particular acceptance question. Detailed dataset and grader design belongs to 4.2.

Keep the experiment narrow enough to repeat. Freeze the tested prompt, input preparation, candidate configuration, and rubric for each run. This records which proposal produced the evidence; it is not a requirement to reproduce identical model wording. Compare candidate revisions on the same acceptance definitions instead of relaxing the definitions when performance disappoints.

Separate offline feasibility from operational value

An offline test can establish observed field quality and processing behavior on its sample. It cannot establish that employees save time in their live workflow. Plan a bounded pilot when the value hypothesis depends on human use, and measure the complete task with those humans.

Anthropic’s success-criteria page includes latency and price alongside task fidelity. Include them in the experiment whenever they constrain the design. Measure the processing path you intend to use, rather than inferring production responsiveness from an interactive demo. Avoid attaching unverified vendor prices or service guarantees to the hypothesis; a test budget is your organization’s decision.

Define the decision after each phase. A failed quality gate can stop the pilot. A passed quality gate with excessive review time can reshape the output. Passing both can justify investment in a production design, with remaining security, integration, and operating questions explicitly identified. A proof of concept is evidence for that investment, not proof that those later obligations are already satisfied.

Each phase ends in a decision that can stop the pilot, reshape the output, or justify a production design.

Key distinctions and trade-offs

Feasibility versus value: A model can generate acceptable output without improving the workflow. Offline quality and live handling time answer different questions.

Representative cases versus impressive examples: Clean examples make a demonstration readable. Realistic edge cases expose the assumption that determines whether the system survives ordinary work.

Risk-first versus feature-first scope: Risk-first scope includes only what can falsify the design. Feature-first scope adds interfaces and integrations before the core uncertainty is resolved.

Stopping versus tuning: A prompt defect may justify another bounded revision. Missing evidence or a failed business-value hypothesis can justify ending the proposal. Choose the next action from the failure, rather than assuming every failure needs more inference.

Architecture / decision scenario

A government procurement team wants to reduce the time spent preparing internal bid-comparison drafts. Three analysts handle forty eligible comparisons per month. They require an approved draft within one working day and authorize only a specific set of procurement documents for the experiment. All quantities are illustrative business constraints.

The team records this hypothesis; the processing budget is an organizational cap, not a vendor price claim:

Capability: Draft evidence-based bid comparisons from authorized documents.
Baseline → target: Reduce median analyst handling time from 90 to 60 minutes.
Constraints: Trace every mandatory requirement; spend at most $2 per case.
Out of scope: Contract award and eligibility decisions stay with officers.
Stop or reshape: A critical failure remains after two prompt revisions.

The riskiest assumption is that the draft distinguishes mandatory conditions from optional statements across contradictory documents. You test that offline before building a portal. The team labels thirty historical comparisons spanning amendments, missing attachments, and conflicting supplier statements. Ten are available for prompt revision; twenty remain held out. That small experiment identifies failure modes but cannot establish a rare-error guarantee.

The expert rubric treats an invented or reversed mandatory condition as a critical failure. The team applies the recorded stop condition to the held-out run. Exact requirement identifiers receive code checks; the officers grade interpretation against the rubric. A failure caused by missing attachments reshapes the intake requirement rather than prompting Claude to invent an answer.

If offline gates pass, a supervised pilot measures preparation plus review time and the one-day turnaround. Passing factuality while taking eighty-five minutes per case defeats the sixty-minute value target. You can test a narrower output, such as evidence extraction, or keep the existing process. Only a useful observed improvement within the quality, data, and budget constraints justifies committing to the production design.

Common exam traps

• Calling a technically successful response proof of business value.
• Building the full interface before testing the assumption that can invalidate the proposal.
• Using only clean invented cases when messy historical inputs determine success.
• Revising the prompt on the cases later described as held out.
• Claiming a small error-free sample establishes zero risk.
• Changing thresholds after seeing results so the proposal always passes.
• Treating a successful proof of concept as completed production readiness.

What to remember

State a hypothesis with a baseline, target, constraints, and defeat condition. Test the most consequential uncertain assumption with representative evidence before expanding the design. Use offline evaluation for feasibility and a bounded human pilot for workflow value; let the results support proceeding, reshaping, or stopping.

Knowledge check

References

• Anthropic, Define success criteria and build evaluations
• Anthropic, Building effective agents