An acceptance test is a sentence you write before you build, stating what you will observe, where you will observe it, and what observation would change your mind. It is not a requirements document and not a promise of a result. The test is the smallest thing that could prove you wrong. If you cannot write it down in a paragraph, the work is not yet defined enough to start.

The order matters: decide first, observe second, build third. Most failed pilots reverse this and build something, then search for a story that justifies it. The method below is deliberately narrow — one decision, one observation, one threshold — because narrow tests survive contact with real constraints.

Start from the decision, not the feature

Ask what decision the evidence will inform. "Should this handoff have an owner named at each stage?" is a decision. "Add a notification system" is a feature. A decision has alternatives, and the test should be able to support either one.

Write the decision in one line, then write the two or three options you would realistically take. If only one option is imaginable, you are not testing anything; you are documenting a foregone conclusion.

Name the observation in countable terms

Evidence has to be something a second person could check. Prefer counts, durations recorded by a person doing the work, or excerpts from existing notes over impressions. The public Handoff desk at aiautomationconsulting.com.de takes exactly this approach: it records work minutes and wait minutes per stage for a workflow of two to eight stages and returns totals, a wait share, and the largest wait with ties named. That output is a description of notes someone typed, not a measurement of the world.

Label your hypothetical example clearly. A worked example might read: hypothetical — an invoice arrives and sits 1,440 minutes before being keyed in over 6 work minutes. The Handoff page itself uses an invented invoice example with 13 work minutes against 4,780 wait minutes and states plainly that the numbers were not measured and are not the result of any engagement. Copy that discipline, not the numbers.

Set the threshold before you look

Write the number that would count as a pass, and the number that would count as a stop, before any data exists. Example thresholds, clearly hypothetical: if in ten sampled items the recorded wait at one stage exceeds the recorded wait at every other stage, the handoff has one dominant queue and we test there first. Or: if fewer than six of ten items can be given a named owner role, the mapping is too incomplete to act on.

A threshold that you adjust after seeing the data is not a test. If you must change it, write down why and treat the earlier run as discarded.

State the unknown you are not resolving

Every honest brief has unknowns. Label them explicitly rather than filling them with plausible language. The agent memory reference at aiagentmemory.com.de is a useful model here: it reports observed fixture metrics on a synthetic corpus of 16 entries, 5 queries, seed 7, k=5 — BM25 mean_recall@k 0.90, mean_precision@k 0.28, MRR 1.00 — and immediately qualifies them as observed numbers on a tiny fixture, not a benchmark. It also states that full JSON output differs between runs and the cause is not yet diagnosed, and that no bit-reproducibility, Python 3.9 compatibility, or external performance guarantee is claimed. That is what an explicit unknown looks like.

Separate illustrative output from evidence

Tools that compute from your own entries produce illustrative output. The statistics worksheet at 13labs.com.de says so directly: outputs are illustrative, generated from the numbers you type, not evidence about the real world, not measurements, and carry no significance claims, p-values or predictions. It also notes that removing an outlier is a judgment call and offers the comparison to show the effect, not as a recommendation.

Apply the same test to your own brief. If a number came from a tool running on your typed input, it is a description of your input. If it came from watching the work happen, say who watched, when, and how many items.

Write the smallest pilot that can answer it

A pilot is acceptable when it can be run in one bounded step, by a named person, within a stated period, and its output can be written in a table. Scope it to one workflow, one queue, or one handoff. If the pilot needs several teams before it produces a single countable observation, cut it down further.

A template you can fill in

Six fields are enough for a first pass:

  • Goal — the decision you are informing, in one sentence.
  • Current workflow — the stages as they exist today, with owner roles where known.
  • Constraints — time, tools, access, and what you will not change during the test.
  • Evidence needed — the countable observation, the source of it, and the threshold.
  • Owner — the person who will collect and record the observation.
  • Next test — the single bounded step that produces the evidence.

Anything you cannot fill in becomes an explicit unknown rather than an invented fact. The private brief builder at /project-brief/ structures exactly these fields and produces a Markdown brief with the unknowns flagged, for download or reset; nothing you type is stored or transmitted.

Common failure modes

Four patterns recur. First, the threshold is a feeling: "it should be faster" cannot fail, so it cannot inform a decision. Second, the observation is a tool output presented as a world measurement. Third, the unknown is hidden — a missing owner or an unmeasured stage quietly assumed. Fourth, the pilot is scaled before it answers anything, which makes the result unattributable.

The worksheet above also limits itself in ways worth copying: it makes no inferential significance claims, computes no p-values, makes no predictions about unseen data, and states that the resample range and count describe only the draws shown, not the population. Scope limits written into the instrument are easier to keep than scope limits written into a separate memo.

When to stop and rewrite

Rewrite the acceptance test if you cannot name the decision, if the observation requires access you do not have, or if the threshold would pass under every plausible outcome. Those are definition problems, not execution problems, and building first will not solve them.

For how this connects to running a workflow and scoring it, read From a working demo to an operating system, and for selecting the bounded step itself, see Design the human handoff and Scope a small implementation pilot.

Sources: public capability descriptions at 13labs.com.de, aiagentmemory.com.de, and aiautomationconsulting.com.de. All figures quoted from those pages are as stated there; examples labelled hypothetical in this guide are illustrative only and were not measured.