Confident-sounding AI analysis built on invisible assumptions is harder to catch than an obviously wrong answer. This prompt pattern forces models to surface what they were guessing while the reasoning is still fresh, not after the fact when recovery is generic and useless.
Where the Problem Lives
You ask a strategy question. The model returns a well-structured, polished answer. You move forward on it. Then, somewhere in the review round, a shaky premise surfaces and the whole thing falls apart.
A prompt engineer at pilot5.ai shared exactly this pattern on r/PromptEngineering. The post comes from u/MyGibbsFreeEnergy, who runs multi-model deliberation pipelines: same question, several frontier models, reconciled answers. The recurring failure he kept running into was models producing confident analyses built on premises they never disclosed. By the time the shakiness surfaced in the critique round, a full round of tokens had already been burned on a flawed foundation.
Why the Standard Fix Doesn’t Work
The obvious solution is a follow-up prompt: “What data would help you answer this?” The author ran that approach for months. The results were generic and useless.
The models weren’t being evasive. They just didn’t know what you cared about. So they served up plausible-sounding context suggestions that looked helpful and were actually noise.
The real fix is different: fold the assumption check into the original answer. Force the model to commit to specifics while the reasoning is still active, not reconstruct it afterward from a cold start.
The Prompt
Add this block at the end of whatever system or user prompt you’re using for the main task:
After your analysis, output a CRITICAL_UNKNOWNS section with this exact structure: CRITICAL_UNKNOWNS:
– What’s missing: [specific data gap that would change your analysis if you had it] Impact: [how your answer would change with that data] My assumption instead: [what you assumed in its place, and why] List 1, 3 such unknowns. Be specific. Vague unknowns are useless, name the data, the source, the time period. NOT: “more context about the market”
YES: “Q3 2025 churn data for the SMB segment, if above 8%, the recommendation flips to retention-first”
Why Each Field Does Something Different
Three things make this pattern work where a follow-up prompt fails:
- The model knows where it guessed. It had to guess to produce the answer, so the hidden assumptions are already there in the reasoning. An external prompt can’t recover them because the model has to reconstruct uncertainty after the fact, and that reconstruction is always generic. Asking mid-response forces specifics.
- “Impact” forces ranking. Not all data gaps are equal. Making the model articulate how each unknown would change the final answer separates the “nice to know” from the “would flip the recommendation.” That distinction is exactly what you need to decide where to spend research time.
- 🔍 “My assumption instead” surfaces the smuggled priors. This is the most valuable field. Before the author added it, models produced answers with invisible premises baked into the logic. Making each assumption explicit means you can check it against real data, challenge it with a second model, or replace it entirely before trusting the conclusion.
What To Do With the Output
Once you have a CRITICAL_UNKNOWNS section, three moves become available that weren’t before:
- Feed the specific gaps to a retrieval system for targeted research before acting
- Ask the user for the missing data directly instead of guessing a second time
- Run a second pass with the assumptions made explicit, so the model reasons from stated premises rather than invisible ones
The author notes this is especially useful in multi-model pipelines where you’re reconciling answers across different models. Each model’s CRITICAL_UNKNOWNS section tells you not just what it concluded, but where the conclusions diverge because of different hidden assumptions.
Use Cases
This pattern performs best on judgment tasks where context determines the answer. Use it for:
- Market entry and competitive strategy analysis
- Business or product diagnosis
- Prioritization decisions with incomplete information
- Any recommendation that depends on data the model doesn’t have access to
Skip it for trivia or closed-domain technical questions. On those, the model’s “unknowns” are mostly fabricated doubt rather than real gaps, and the output won’t be useful.
One Caveat on Weaker Models
Smaller models sometimes produce generic unknowns even with the structure enforced. Two adjustments that help: drop temperature to 0.3, and include the NOT/YES rejection example directly in the prompt. The example does real work because it shows the model what level of specificity is required, not just tells it.
Prompt of the Day
After your analysis, output a CRITICAL_UNKNOWNS section with this exact structure: CRITICAL_UNKNOWNS:
– What’s missing: [specific data gap that would change your analysis if you had it] Impact: [how your answer would change with that data] My assumption instead: [what you assumed in its place, and why] List 1, 3 such unknowns. Be specific. Vague unknowns are useless, name the data, the source, the time period. NOT: “more context about the market”
YES: “Q3 2025 churn data for the SMB segment, if above 8%, the recommendation flips to retention-first”
Add it to the end of any strategy, diagnosis, or prioritization prompt. One extra section, and suddenly you know exactly where to trust the answer and where to verify it first.
The full post with a working Italian cybersecurity market example is in the original thread at r/PromptEngineering. The output excerpt alone is worth seeing.
Frequently Asked Questions
Q: Why is this better than just asking the model what data is missing?
When you ask models “what data would help?”, they often return generic suggestions because they don’t know what matters to you. By asking them to name what they assumed instead, you’re forcing a harder question. They have to commit to the specific premises their analysis rests on, which is much harder to dodge with vague suggestions.
Q: How specific should my CRITICAL_UNKNOWNS be?
Specific enough that someone could actually go find or measure the data. “More market context” won’t work. “Q3 2025 churn data for the SMB segment. If above 8%, the recommendation flips to retention-first” is the level you want. The test: could a colleague understand exactly what data you need and where to find it?
Q: What if I only have one or two unknowns instead of three?
That’s fine. The pattern suggests 1 to 3, so one solid unknown is enough. Quality matters more than quantity. One critical assumption you surface can completely change your decision, and it’s usually harder to identify than you’d expect.
Q: Does this add a lot of prompt overhead?
The extra text is minimal, and it pays off quickly. By catching weak premises before you run a full generation round on bad assumptions, you avoid wasting tokens downstream. It’s a small upfront cost that prevents larger ones later.
A prompt pattern that surfaces hidden assumptions — not just knowledge gaps
by u/MyGibbsFreeEnergy in PromptEngineering