assumption-audit

name

assumption-audit

description

Before finalizing any analysis, recommendation, or decision made under incomplete information, surface the load-bearing assumptions, tag each as supported or unsupported by the given evidence, and stress-test the conclusion against the weakest one. Use this whenever you are asked "should we do X", to recommend or advise, to compare options, or to make strategy, hiring, budget, planning, prioritization, or operational judgment calls — even when the request doesn't mention assumptions or uncertainty. If the answer would rest on anything not directly stated in the given information, this skill applies.

Assumption Audit

Conclusions under incomplete information rest on assumptions, and the ones that go unstated are the ones that fail silently. Intelligence tradecraft treats this as a standard failure mode: analysts fill gaps with plausible-seeming beliefs, then present the conclusion as if it followed from evidence alone. The fix is not more caution — it is making the assumptions visible before the conclusion hardens, so the reader (and you) can see exactly which unverified belief the recommendation would die with.

Process

1. Draft your reasoning, then — before writing the conclusion — list the assumptions it actually depends on. Load-bearing only: an assumption belongs on the list if the conclusion changes when it fails.
2. Tag each assumption supported (follows from information you were given or can verify) or unsupported (plausible, but nothing provided confirms it). Be strict: "usually true in general" is not support from the given information.
3. Identify the weakest load-bearing assumption and ask what the recommendation becomes if it is false. If the answer flips or degrades badly, the conclusion must say so — that sensitivity is part of the answer, not a footnote.
4. Only then finalize. Keep what was given (data, quotes, stated constraints) visibly distinct from what you inferred, so no inference silently borrows the authority of evidence.

What this looks like

• Hiring: "Recommend the senior candidate" rests on "budget covers senior comp" (unsupported — no budget was given); if false, the recommendation flips to candidate B.
• Market analysis: flat sales + a competitor's launch suggests lost share — but "the decline started after their launch" is an inference; the data only shows Q3 totals.
• Code migration: "cut over this weekend" assumes traffic is low on weekends (unsupported — no traffic data provided); if false, the rollback window disappears.

Output rules

• Never narrate your own diligence ("I carefully checked...", "having verified the assumptions..."). The audit shows in the work product — the tagged list, the sensitivity statement — not in self-description.
• The audit happens before and while producing the answer; only its results appear in the output, and only where they matter. A simple question with solid givens may need just one line noting the key unsupported assumption.
• Keep length proportionate to the task — the audit sharpens the answer, it does not pad it.
• State the recommendation's sensitivity to the weakest assumption in plain terms: what changes, and how the reader could check the assumption cheaply if they can.

Grounding: CIA, A Tradecraft Primer: Structured Analytic Techniques (2009), Key Assumptions Check; ICD 203, IC Analytic Standards — distinguish underlying intelligence from assumptions and judgments.