| 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
- 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.
- 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.
- 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.
- 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.
