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.