How to develop and assess assumption testing in AI-enabled work

Find assumptions that can change the work

An assumption is not every unknown. It is a proposition treated as sufficiently true for a plan, calculation, classification, or recommendation to proceed. The most important assumptions combine three properties: they influence the output, their truth is uncertain, and being wrong would matter.

AI assistants can introduce assumptions silently. They may infer that a source is current, a category is exhaustive, a number uses the same denominator as another number, a workflow has authority to use data, or a missing fact is typical. Fluency does not make any of those premises reliable.

The AQuA Book's guidance on analytical quality assurance emphasizes proportionate assurance across the analysis life cycle, verification and validation, and explicit recording of assumptions, including who made and approved them. NIST's AI Risk Management Framework similarly describes test, evaluation, verification, and validation work that can include checking assumptions about system design, data collection, measurements, and the intended context. These sources do not supply a universal workplace checklist, but they support treating assumptions as reviewable evidence rather than background intuition.

Start by locating assumptions in five places:

Do not ask only, “What assumptions did the AI make?” Ask what the entire workflow assumes, including the human brief, source pack, spreadsheet, model output, and final synthesis.

• inputs: completeness, freshness, provenance, definitions, and permitted use;
• transformation: formulas, categories, joins, prompts, exclusions, and model interpretation;
• context: audience, authority, constraints, timing, and operating conditions;
• causal link: why an action is expected to create an outcome;
• decision threshold: what must be true for an option, risk, or recommendation to remain acceptable.

Use a BREAK assumption card

BREAK turns a hidden premise into a bounded test:

| Field | Question | Required record | | --- | --- | --- | | Belief | What proposition is currently being relied on? | One falsifiable sentence, not a vague concern | | Reliance | Which claim, calculation, action, or threshold depends on it? | Exact downstream dependency | | Evidence | What supports and contradicts the belief now? | Source, date, applicability, and gap | | Adverse case | What observable result would break or narrow it? | Counterevidence, boundary, or break point | | Knowledge action | What is the smallest useful test, who owns it, and what follows? | Method, owner, deadline, and dispositions |

Write the belief so that evidence can disagree with it. “The data is good enough” is not testable. “At least 95% of rows used in the monthly total have a unique account identifier and a transaction date in the reporting period” is testable, though its threshold still needs a contextual rationale.

Reliance determines priority. If an assumption changes only a decorative sentence, it does not deserve the same effort as one that changes a payment, public claim, safety control, or irreversible commitment. Record consequence and reversibility before choosing the test.

The evidence field should contain both supporting and challenging material. A model-generated explanation is not independent support for an assumption embedded in the model's own answer. Prefer direct inspection, authoritative records, reproducible calculations, subject-matter confirmation, or a bounded trial suited to the proposition.

The adverse case makes the exercise falsifiable. It can be a counterexample, failed reconciliation, missing approval, observed range, or changed source. If no possible finding would change the belief, the card records a commitment, not a test.

Worked artifact: testing an automated triage assumption

Consider an original synthetic operations example. A team is preparing a weekly summary of incoming service requests. An AI assistant has grouped free-text messages into four themes. The draft summary says the themes cover the workload well enough to assign next week's review capacity.

The team does not know whether that statement is justified. It creates this BREAK card:

Belief: The four-theme scheme assigns at least 90% of in-scope messages to a single operationally useful theme without hiding materially different request types.

Reliance: The proposed staffing split, two priority statements in the summary, and the decision not to review an “other” queue all depend on the scheme.

Evidence: The AI output contains a label and short rationale for 240 messages. A human reviewed 20 examples while developing the prompt, but the examples were not randomly selected and no independent review has tested the final scheme. Twelve messages received low-confidence rationales. The 90% figure is a locally proposed decision threshold, not an external benchmark.

Adverse case: The assumption narrows if more than 10% of a representative sample cannot be assigned cleanly. It breaks for staffing purposes if the “other” or disagreement cases contain a distinct request type with a different handling time, deadline, or specialist owner.

Knowledge action: A reviewer who did not write the prompt draws a stratified sample of 48 messages: 10 from each named theme and all eight low-confidence or “other” cases. The reviewer assigns a theme without seeing the AI label, notes mixed cases, and flags any request type requiring different handling. The owner then reconciles disagreements and records one of four dispositions: retain the scheme, revise definitions and retest, add a fifth theme, or do not use the scheme for staffing.

The test is not designed to prove that AI categorization is generally accurate. It checks whether this scheme is fit for this weekly decision under a declared threshold. If the independent review finds only four disagreements but all four are urgent specialist requests hidden inside a broad theme, the raw agreement rate may look acceptable while the assumption still fails its operational boundary.

The card also changes the draft summary. Before testing, the team replaces “the four themes cover the workload” with “the draft grouping contains four themes; independent coverage and operational-use checks are pending.” That wording preserves the difference between an output and verified evidence.

Match the test to the assumption

Different premises need different checks:

The UK Green Book 2026 recommends sensitivity and scenario techniques for uncertainty and notes that simple what-if questions may be proportionate for lower-cost, lower-risk proposals. In an ordinary work product, a useful sensitivity test can be as simple as changing a pivotal input through a plausible range and observing whether the conclusion or action changes. This differs from scenario reasoning: the focus here is one relied-upon proposition and the evidence that would break it, not several coherent future worlds.

Testing should stop when the evidence is proportionate to the decision, not when every uncertainty disappears. Record residual uncertainty and its consequence. If a cheap test cannot reduce a high-consequence uncertainty, narrow the action, add human review, make the step reversible, or escalate it to the appropriate owner.

• source assumption: open the primary record, confirm date and scope, and compare the quoted claim with the original context;
• calculation assumption: reconstruct a small case independently, vary units and boundaries, and reconcile totals;
• classification assumption: use blind or independent examples, inspect disagreement, and test consequential edge cases;
• causal assumption: articulate the mechanism, search for rival explanations, and prefer a reversible pilot when direct evidence is limited;
• authority assumption: confirm the owner, permission, policy, and escalation route rather than inferring them from past practice;
• operating assumption: test capacity, timing, handoffs, failure recovery, and the conditions under which the process will run.

Practice with an assumption hunt and break test

Give a learner a short AI-assisted work product plus its source pack. Ask them to mark every sentence that relies on an unstated premise. They then rank the assumptions by downstream consequence, current evidence, and reversibility, and create BREAK cards for the top two.

For the first card, supply evidence that supports the belief. For the second, supply a boundary case that partially contradicts it. The learner should update the reliance and disposition rather than defensively preserving the original output. A good response may keep an assumption with narrower scope, replace it, request more evidence, or change the action.

AI can help propose rival assumptions, design edge cases, or translate a premise into a falsifiable sentence. The learner remains responsible for selecting an independent test, inspecting the relevant evidence, and deciding what the result permits. Re-prompting the same model for reassurance is not independent verification.

Assess assumption testing from observable evidence

Review the original artifact, BREAK cards, test records, revisions, and final communication:

Do not reward the number of assumptions listed. A long generic risk register can avoid the one premise that controls the conclusion. Strong performance isolates the decisive premise and produces a check whose result can change the work.

• identification: pivotal assumptions are surfaced from inputs, transformations, context, causal logic, and thresholds;
• falsifiability: each selected belief is precise enough for evidence to challenge it;
• prioritization: testing effort follows consequence, uncertainty, and reversibility;
• independence: the check does not merely ask the same system to endorse its own output;
• boundary quality: adverse cases target how the assumption could fail in this decision;
• test fit: the method matches the proposition and uses appropriate samples, records, or subject-matter review;
• disposition: results lead to a clear retain, narrow, revise, replace, stop, or escalate decision;
• communication: residual uncertainty and the limits of the test remain visible in the final work.

Verify the test before closing the card

Run a closure review. Confirm that the tested proposition matches the original reliance, the sample or evidence covers the relevant population, and the adverse case was genuinely examined. Check whether the tester was sufficiently independent for the consequence involved. Recalculate any threshold result from the retained records.

Then inspect the downstream artifact. If the assumption narrowed or broke, every dependent claim, number, or action should be revised. If the assumption was retained, state what the test actually supports and what it did not examine. Date the result and name the condition that would reopen it, such as a new data source, changed workflow, different population, or material incident.

Assumption testing provides disciplined evidence about a premise; it cannot establish that a work product is correct or safe in every relevant condition. In a Two Prune assessment, the BREAK card and resulting revisions can provide task-bounded evidence about Verification & Risk Control, Evidence Navigation, Context Framing, and Judgment & Synthesis. They do not establish general workplace capability and do not make an employment decision.

Sources

UK Government: The AQuA Book

• UK Government: The Green Book 2026
• NIST: Artificial Intelligence Risk Management Framework 1.0

Sources: [1] [2] [3]