ASSUMPTION CHECK

Identify the assumptions that materially support the conclusion or schedule, distinguish stronger assumptions from weak or unverified ones, and rank them by how much changing each assumption could change the result. Ignore trivial assumptions unlikely to affect the outcome.

A Power Mode is an instruction pattern, not a feature of the AI. Nothing recognises the name — the wording underneath it does the work, and you can copy it from this page.

From the book. Chapter 12 / Part VII — ASSUMPTION CHECK

What it actually does

Every plan rests on things being true. Some are facts, some are estimates, some are expectations, and some are assumptions nobody has said out loud. ASSUMPTION CHECK points the model at that last category specifically.

The instruction asks it to separate the load-bearing assumptions from the incidental ones, then rank them by how much changing one would change the result. The ranking is what makes the output usable — a flat list of everything that technically qualifies as an assumption is not a finding.

The important word is materially. Without it, assumption checking becomes a hunt for every unstated premise in the document.

When to use it

Use ASSUMPTION CHECK when you already suspect the weakness is something the work takes for granted, and want those beliefs ranked by how much each would change the outcome.

It is the primary mode for this job: pressure-test something before you commit to it.

When not to use it

This is the section worth reading. Using only what the work requires is the point; a mode applied to the wrong shape of problem costs you a worse answer than plain language would have given.

Use a different mode instead

REDTEAM fires when you want a plan or argument attacked but cannot yet say where it is weak.
BUYER OBJECTION LENS fires when you need someone specific to agree, and want their reasons for refusing rather than a critique of what you are showing them.
PREMORTEM fires when you fix a point in the future, declare it a failure, and ask what caused it.
COUNTEREVIDENCE fires when you have a conclusion you believe and want the credible case against it, not a critique of how it is argued.

Use no mode at all

Assumptions are not material to the decision.
The user already knows the exact dependency and can test it directly.

There is no bonus for naming a mode when plain language is clearer. If you can already state the exact question, ask it.

Its failure mode

Long lists of trivial assumptions or treating all assumptions equally.

Starter instruction

Paste this above your task. It is the whole mode — there is nothing else to switch on.

Identify the assumptions that materially support this conclusion. Separate stronger assumptions from weak or unverified ones, and rank them by how much changing them could change the result. Ignore assumptions unlikely to change the recommendation, plan, estimate, or decision.

The same task, run both ways

Blind run. Separate sessions per arm, Temporary Chat, no memory, no tools attached. Neither prompt named a mode. No arm searched.

The task: We estimate a software implementation will take 12 weeks because: - requirements: 2 weeks - configuration: 4 weeks - testing: 3 weeks - training: 1 week - deployment: 2 weeks

Baseline — "Review this estimate"

The arithmetic is correct: 2 + 4 + 3 + 1 + 2 = 12 weeks.
The main issue is that the estimate appears to assume every phase happens sequentially with no overlap and no contingency. That makes 12 weeks a plausible baseline, but not necessarily a robust project estimate.
I’d review these assumptions:

[…]

I would present 12 weeks as the base schedule, rather than automatically treating it as the committed completion date. For example, a modest 10–20% schedule contingency would put the planning range at roughly 13–15 weeks, unless some activities can overlap.
It would also be stronger to show dependencies. Training preparation could overlap with testing, for example, while deployment may depend on successful UAT rather than simply beginning after three weeks of testing.

ASSUMPTION CHECK — "Rank them by how much changing them could change the result"

The **12-week estimate is mathematically correct only if the five phase estimates are valid and the phases effectively run sequentially**. The assumptions below materially support that conclusion.

[…]

### Weakest and most decision-relevant assumptions

The biggest uncertainties are **sequential execution, scope stability, configuration duration, testing/rework, and resource/dependency availability**. Those should be validated before treating **12 weeks as a reliable project completion date rather than a simple bottom-up estimate**.

In particular, I would express the conclusion as: **“12 weeks is the estimated duration under a sequential, no-delay, stable-scope plan.”**

Both arms notice the phases are assumed to run end to end. The baseline accepts that frame and pads it — a 10–20% contingency, so 13–15 weeks. The mode arm refuses to restate the number at all and instead states the conditions under which it means anything: "12 weeks is the estimated duration under a sequential, no-delay, stable-scope plan."

The baseline is not wrong and it did spot the sequencing assumption. A padded range is also a reasonable thing to hand a sponsor. The difference is that one answer survives being questioned about what it depends on and the other does not — and only the mode arm asked whether the phase figures were elapsed time or effort, which is the one assumption that could move the estimate in either direction.

Extracts are verbatim from 06_Test_Lab/Experiments/TL-023_ASSUMPTION_CHECK_Raw_Outputs.md.

Related modes

Try it on your own work

Describe what you are actually doing and the Builder writes the full prompt — mode, context, output shape, and the verification step. It picks the mode from your description, which is why this link does not carry one.

Open the Prompt Builder →