Most bad calls aren't the result of bad evidence. They're the result of a true-sounding assumption nobody stopped to check — the supplier will make the deadline "because they always have," the competitor won't retaliate "because it wouldn't be rational," the model's training data "looks representative enough." Assumptions like these do real work in an analysis, but they're rarely written down, which means they're never tested and never revisited.
A Key Assumptions Check (KAC) is the fix: a short, deliberate exercise where you list every supposition your analytic line depends on, then interrogate each one. Richards Heuer and Randolph Pherson place it among the handful of "core" structured analytic techniques — alongside Analysis of Competing Hypotheses (ACH) and Indicators — because it's cheap to run and catches a specific, well-documented failure mode: analysts overdraw conclusions from limited data and unconsciously assume other people reason the way they do (a trap known as mirror-imaging).
This tutorial pairs with the interactive Key Assumptions Check tool. Open it in another tab and build your list as you read — everything auto-saves in your browser, and each step below maps to a feature in the tool.
When to use a Key Assumptions Check
Run a KAC whenever:
- You're about to commit to a judgment and haven't yet asked what has to be true for that judgment to hold
- The situation involves a foreign actor, competitor, or counterpart whose reasoning you might be unconsciously modeling on your own (mirror-imaging risk)
- A project has been running for a while and its founding assumptions haven't been revisited since the early days
- You're about to hand a conclusion to a decision-maker who will ask "what are we taking for granted here?"
It's most valuable early-to-mid project — after a Mind Map or Chronology has surfaced the shape of the problem, but before or alongside formal hypothesis testing in ACH, since ACH's evidence weighting is only as sound as the assumptions underneath it.
The core idea: name it before you can test it
An assumption you haven't stated is an assumption you can't examine. The KAC method has one central discipline: get every supposition — obvious and hidden — onto a list as an explicit, single sentence, before you try to judge whether any of them are true.
The hidden ones are the point. Obvious assumptions ("the report is a reliable source") are usually already being managed somewhere in your head. Hidden assumptions — the ones that only surface when someone probes, like "the supplier's leadership actually has the authority to prioritize this order" — are the ones that quietly decide the outcome of an analysis and never get challenged.
The method, step by step
Brainstorm the full list — obvious and hidden
Write down every supposition your current analytic line depends on. Don't filter yet; a KAC that starts short usually stays short. For each one, decide:
- Obvious — something the team is consciously aware of assuming
- Hidden — something that only surfaces when you ask "wait, why do I believe that?"
If you already have a Mind Map or a Chronology for this project, don't start from a blank page. In the tool, use Seed candidates to pull in nodes you tagged "assumed" during brainstorming, or gaps that surfaced during chronology review — each seeded assumption keeps a link back to where it came from.
Keep each assumption atomic — one claim per statement. The tool checks incoming assumptions for bundled claims ("the supplier has capacity and the shipping lane will stay open") and offers to split them, because a compound assumption can be half-true in a way that hides which half is the problem.
Unpack each one
For every assumption, answer two questions and write down the answers:
- What makes you think it's true? — the evidence or reasoning behind it
- What would have to happen for it to be false? — the condition that would break it
This step is where mirror-imaging usually gets caught. "The competitor won't cut prices" sounds obvious until you write down why — and notice the reason is really "I wouldn't cut prices in their position," which is a claim about you, not them.
In the tool, each assumption has a rationale field for exactly these two answers, plus a place to attach citations — including cross-links to evidence rows in an ACH matrix or events in a Chronology — with a stance of whether the citation supports or undermines the assumption.
Rate each assumption
Sort every assumption into one of three bins:
| Rating | Meaning | |---|---| | Solid | Supported by strong evidence — safe to build on | | Caveated | Correct with qualifications — some supporting evidence, some counter-evidence | | Unsupported | Weak evidence, or alternatives not sufficiently considered |
Be honest about the difference between "I believe this" and "I have evidence for this." Most of the value in a KAC comes from admitting that some load-bearing assumptions belong in the third bin.
Ratings aren't final — the tool timestamps and attributes every rating change, and keeps prior ratings visible in a version trail, so you can see how confidence in a given assumption shifted as the project went on.
Refine the list
Once the first pass is rated, clean it up:
- Merge assumptions that turn out to be duplicates
- Split any that turn out to be compound after all
- Add newly surfaced assumptions — unpacking one assumption often exposes another underneath it
In the tool, merged and split assumptions retain a link back to their origin, so the analytic trail stays traceable even after the list has been reorganized.
Act on the Unsupported bin
Every assumption rated Unsupported is a key uncertainty — Heuer and Pherson single these out as the ones that merit real attention, because they're the load-bearing suppositions nobody has actually confirmed.
For each one:
- Turn it into a concrete collection requirement or research question — what evidence, if you got it, would resolve this?
- Mark it monitored and link it to an Indicator so future evidence updates prompt a re-review automatically
The tool keeps a dedicated key-uncertainties view, separate from the main list, so these don't get lost among the assumptions you've already resolved.
A KAC rating is not a probability, and "Solid" is not "certain." The exercise tells you where your analytic line is exposed, not how likely it is to be right. If you need an actual probability estimate, that's Bayesian territory — see Bayesian Updating: From Prior to Posterior.
Revisit it — don't let it go stale
An assumption that was Solid six months ago can quietly become Unsupported as a situation evolves, even with no deliberate re-check. Two guardrails keep a KAC alive instead of becoming a one-time form:
- If you downgrade a rating (say, Solid to Unsupported) after that assumption has been cited in an ACH matrix or a written judgment elsewhere in the project, the tool flags every downstream artifact that relied on it so you know exactly what needs a second look.
- If a project sits untouched past a configurable interval, the tool nudges you to revisit the list, since staleness is easy to miss when nothing has obviously changed.
Save a new version whenever you make a real pass through the list — the version history and diff view show what was added, re-rated, merged, or retired between checks, which is what makes the analysis defensible later.
Resolve or acknowledge before you finalize
The tool won't let you export a final product while a key uncertainty sits unresolved and unacknowledged. Before export, every Unsupported assumption needs either:
- A rating change backed by new evidence, or
- An explicit gap acknowledgment — you're aware it's unresolved, and you're saying so in the final product rather than quietly hoping no one asks
This is the guardrail that turns "we didn't think of that" into "we flagged that and told you it was open." One is a process failure; the other is a defensible judgment call.
A worked example
Dana, an intelligence analyst, is drafting an assessment of a foreign supplier's ability to meet a delivery deadline. She already has a Chronology of known events and a Mind Map of key actors, and starts a KAC seeded from both.
Three assumptions come in pre-populated from Mind Map nodes she'd tagged "assumed." She adds two more by hand, including one she only notices while re-reading her own draft:
"The supplier's leadership has the authority to prioritize this order over competing domestic contracts."
She tags it hidden — it's closer to a mirror-imaging risk (assuming their org chart works like hers) than a fact she's confirmed.
Working through the ratings: two assumptions go Solid (backed by prior shipment records), one goes Caveated (partial evidence, but from a single source), and the authority assumption goes Unsupported — she has no direct evidence either way. It's automatically pushed to her key-uncertainties view, where she generates a collection requirement: "Confirm supplier leadership's contractual authority over prioritization decisions," and links it to an indicator she's already tracking.
Two days later, new reporting downgrades the single-sourced Caveated assumption to Unsupported. The tool flags that this assumption is cited as support in her in-progress ACH matrix, prompting her to re-check that hypothesis's score before finalizing anything.
At export time, one key uncertainty — the leadership-authority question — is still unresolved. Dana acknowledges it explicitly, adds a caveat sentence to her written product, and the export proceeds with that acknowledgment logged alongside it.
Common pitfalls
- Only listing the obvious ones. The assumptions worth checking are usually the ones nobody said out loud. If your list has no hidden-tagged entries, look harder.
- Rating on gut feel instead of evidence. "Solid" should mean you could point to why, not that it feels safe.
- Treating the list as a one-time form. An assumption checked at kickoff and never revisited is a snapshot of what you believed on day one, not a live check on what you believe now.
- Letting downgrades sit quietly. If a Solid assumption slips, anything built on top of it needs a second look — not a shrug.
- Confusing "unresolved" with "ignored." An open key uncertainty isn't a failure. An open key uncertainty nobody told the reader about is.
Try it
Build your first list in the interactive Key Assumptions Check tool — seed candidates from a Mind Map, Chronology, or ACH matrix, tag assumptions obvious or hidden, rate them Solid / Caveated / Unsupported with a timestamped confidence trail, convert key uncertainties into collection requirements with indicator monitoring, and export only after every gap is resolved or explicitly acknowledged. No account needed; everything stays in your browser.
To put your resolved assumptions to work weighing evidence against competing explanations, continue with Analysis of Competing Hypotheses (ACH).