Bounded
Can it stop before cost, time, or tool use escapes?
COURSE 001 · SHIP IT
A runtime becomes useful only when a real user can trust the outcome.
Keep the technical spine. Add the FDE layer: shape one real job, deploy the narrowest useful workflow, break it deliberately, measure what remains true, and publish the evidence.
THE PUBLIC BENCHMARK
Six claims. Six forms of proof.
Do not grade the demo. Grade the system under pressure.Observable
Can an operator explain its current state and history?
Recoverable
Does useful work survive crashes, waits, and deploys?
Evidence-backed
Can a reviewer inspect the basis of every material claim?
Cost-aware
Can you explain and constrain spend per successful outcome?
Useful
Does a real user complete the job better with the system?
CUSTOMER-SHAPED CAPSTONE
From a user problem to public evidence.
Use the Vendor Review Agent if you need a complete example. Replace it only when you have access to a real user and a job with observable value.
- 01A one-page Field Brief
Shape the job
Interview one user. Name the decision they need to make, the evidence they trust, the action the system may take, and the harm of being wrong.
- 02Acceptance tests + invariants
Define the contract
Turn the job into observable success criteria. Set budgets, human-control points, forbidden actions, and the six scorecard targets before adding tools.
- 03A deployed workflow
Ship the narrow path
Implement one useful end-to-end path. Keep authority in durable state, preserve evidence as artifacts, and expose the run to an operator.
- 04A benchmark run
Break and measure
Run the failure suite against a pinned fixture, model, prompt, and fault schedule. Record raw results rather than rewriting the story after the run.
- 05A Field Report
Return to the user
Put the system in front of the user. Record where they hesitated, overrode it, or still worked around it. Publish limitations and the next engineering decision.
COPY THIS TEMPLATE
The Field Brief
Write this before architecture. If an answer is unknown, mark it unknown: do not replace discovery with an assumption.
USER Who does this job today? JOB What decision or action must they complete? EVIDENCE What must the workflow inspect and preserve? BOUNDARY What may it do alone? What needs approval? SUCCESS What observable result is better than today? FAILURE COST What happens when it is slow, wrong, or unavailable? BUDGET Maximum time, cost, tool calls, and retries per run.
FINAL DELIVERABLE
Publish a Field Report, not a victory lap.
Claim
The narrow user outcome and the operating conditions you tested.
Method
Versions, fixtures, fault schedule, budgets, rubrics, and acceptance criteria.
Evidence
Scorecard, traces, event timelines, cost ledger, screenshots, and user notes.
Failures
What broke, why it broke, what changed, and which failures remain open.
Limits
What the result does not establish and where the workflow should not be used.
Reproduce
Repository, pinned configuration, commands, fixtures, and expected output.