The Three-Rule Framework: From Document Extraction to Business Scenario Building

This is the third post in a series about a small set of prompt rules with a surprisingly wide reach.

In the first post, I showed how three rules — Force Blank, Penalize Guessing, Show the Source — stop AI from silently guessing when extracting data from contracts and invoices. In the second post, I adapted them for alternate history worldbuilding, where the same rules keep lore consistent and real history accurate.

This post takes the final step: generalizing the three rules into a framework that works for business scenario building — strategic planning, KPI development, project risk assessment, financial modeling, market entry analysis, and any other context where you’re using AI to think about the future.

Why Scenario Building Is Vulnerable to the Same Problem

Scenario planning has a long intellectual history. RAND developed Assumption-Based Planning (ABP) for the U.S. Army in the 1990s. Shell pioneered corporate scenario planning in the 1980s under Peter Schwartz. The Oxford Scenario Planning Approach, described in a December 2025 MIT Sloan article, now integrates generative AI into the process itself.

All of these methodologies share a core principle: make your assumptions explicit. RAND defines an assumption as “an assertion about some characteristic of the future that underlies the current operations or plans of an organization.” Every plan has them. Most are invisible. The ones that stay invisible are the ones that cause failures.

Now consider what happens when you hand your business data to an AI and ask it to build a scenario. The model does exactly what it does with contracts and fiction: it fills gaps. Revenue growth for Q4? The model picks a plausible number. Competitive response to your market entry? The model invents one. Timeline for regulatory approval? The model estimates. Customer churn under the new pricing? The model generates a figure.

Every one of these is an assumption. None of them are labeled as such. The scenario reads like a coherent analysis, backed by data — but some of the “data” is real, some is derived, and some was fabricated to make the narrative hold together. You can’t tell which is which.

This is the same problem in its third incarnation. And it responds to the same three rules.

The General Pattern

Across three domains, the same structure repeats:

The underlying logic is always the same: distinguish what is known from what is invented, and make the boundary visible.

For business scenarios, the “canon” has two layers — just like worldbuilding:

1. Verified data — things you know from actual measurements: last year’s revenue, current headcount, signed contracts, measured KPIs, market data from credible sources
2. Established constraints — things that are decided, not speculated: budget limits, regulatory requirements, contractual deadlines, board-approved targets

Everything else — market growth estimates, competitive behavior, customer adoption rates, technology readiness timelines — is an assumption. And assumptions come in two flavors: ones you’ve thought about and can defend (even if uncertain), and ones the AI just made up because the scenario needed a number.

The three rules exist to separate these categories.

The Three Rules for Business Scenario Building

Rule 1: Force Blank → Flag Unknown Variables

When the AI encounters a variable it doesn’t have data for, it should say so — not invent a plausible value.

The gap labels for business scenarios split into two types:

• [DATA GAP] — a factual input the scenario needs but that hasn’t been provided or isn’t available. Example: “This projection requires customer acquisition cost (CAC) for the DACH region; no data was provided.”
• [ASSUMPTION GAP] — a strategic or behavioral assumption the scenario relies on but that hasn’t been explicitly stated. Example: “This scenario assumes competitor X will not lower prices in response. This assumption has not been validated.”

This is where RAND’s ABP framework and the three rules converge most directly. Dewar and his colleagues at RAND argue that every plan has a “ghost scenario” — the implicit, unstated set of assumptions about the future to which the plan is suited. The most dangerous assumptions are the ones nobody realized they were making. Forcing the AI to flag gaps is a practical way to surface the ghost scenario.

Rule 2: Penalize Guessing → A Silent Assumption Is Worse Than a Known Unknown

The business version of “a wrong answer is 3× worse than a blank” is this:

A hidden assumption baked into the scenario is worse than an explicitly flagged uncertainty. When you don’t have data, flag the gap — don’t fill it with a plausible number.

Why is this more dangerous in scenarios than in document extraction? Because scenarios compound. A single unflagged assumption about market growth feeds into revenue projections, which feed into headcount planning, which feeds into budget allocation, which feeds into board presentations. By the time the assumption fails, six months of planning has been built on top of it.

ABP calls these “load-bearing assumptions” — the ones whose failure would require fundamental changes to the plan. The three-rule framework surfaces them before they bear load.

Rule 3: Show the Source → VERIFIED / ASSUMED / PROJECTED

Every number, every trend, every behavioral claim in the scenario gets one of three tags:

• (VERIFIED) — based on actual data you’ve provided: financial reports, signed contracts, measured KPIs, credible third-party research with a citation
• (ASSUMED) — a belief about the future that the scenario relies on but that could be wrong. The model must state the assumption explicitly: “Assumes 15% annual growth in segment X, consistent with 2023–2025 trend”
• (PROJECTED) — a value derived or calculated from verified data and stated assumptions. The model must show the derivation: “Projected from Q1–Q3 actuals at current run rate”

The critical distinction between ASSUMED and PROJECTED: an assumption is a belief you bring to the scenario; a projection is a calculation the model performs using your data and assumptions as inputs. Assumptions can be challenged (“what if growth is 5% instead of 15%?”). Projections can be audited (“show me the calculation”).

This maps directly onto what scenario planning practitioners call “sensitivity analysis”: identifying which assumptions the scenario’s conclusions are most sensitive to. With source tags in place, you can immediately see which conclusions rest on verified data (stable) and which rest on assumptions (fragile). That’s where your attention should go.

The Combined Prompt

Here is the full framework as a system prompt. Replace the bracketed placeholders with your specific context.

You are my scenario planning analyst. We are building a [TYPE: business plan / market analysis / project risk assessment / KPI framework / budget scenario] for [CONTEXT: company, project, product, market].

Your task is to produce analysis that is transparent about what it knows, what it assumes, and what it doesn’t know. Follow these rules strictly:

Rule 1 — Flag unknown variables:
• If the scenario requires data that has not been provided, do not invent a plausible value. Use [DATA GAP: description of what data is missing and why it matters].
• If the scenario relies on a strategic or behavioral assumption that has not been explicitly validated, flag it with [ASSUMPTION GAP: description of the unstated assumption].

Rule 2 — Do not fill gaps silently:
• A hidden assumption baked into the analysis is worse than an explicitly flagged uncertainty.
• When data is missing, flag the gap. Do not generate a plausible-sounding number.
• When an outcome depends on assumptions about competitor behavior, market dynamics, regulatory decisions, or customer response, state the assumption explicitly rather than embedding it as fact.

Rule 3 — Source labeling:
Tag every significant claim, number, or conclusion with its source:
• (VERIFIED) — based on actual data I provided or credible, cited third-party data
• (ASSUMED) — a belief about the future that the scenario depends on. State the assumption and what it is based on.
• (PROJECTED) — calculated or derived from verified data and stated assumptions. Show or describe the derivation.
• For every ASSUMED tag, briefly state what would change if the assumption is wrong.

Example: Market Entry Scenario

Here’s what the output looks like when the rules are active. Imagine asking the AI to assess a SaaS product launch in a new market:

Compare this to what the same model would produce without the rules: a single confident revenue projection of €310K, a specific market share percentage, an assumed CAC that looks like data, and no indication of which numbers are real and which are invented.

The tagged version takes thirty seconds longer to read. It saves weeks of planning on false foundations.

Applications Beyond Strategy

The same framework adapts to any structured planning context:

KPI Development: When defining KPIs for a new initiative, tag each target as VERIFIED (based on historical baseline), ASSUMED (based on industry benchmarks or management expectations), or PROJECTED (calculated from verified inputs). Flag any KPI that lacks a reliable baseline with [DATA GAP]. This prevents the common failure mode where AI-generated KPI dashboards contain a mix of real metrics and invented benchmarks with no way to tell them apart.

Project Risk Assessment: For each identified risk, tag the probability and impact as VERIFIED (based on historical incident data), ASSUMED (based on expert judgment or analogy), or PROJECTED (derived from a model). Flag risks where neither data nor expert input exists with [ASSUMPTION GAP]. The result is a risk register that honestly distinguishes evidence-based risks from plausible-sounding guesses.

Budget Scenarios: Tag every line item. Fixed costs from signed contracts are VERIFIED. Headcount-dependent costs using planned hiring are PROJECTED (with the hiring plan as a stated assumption). Revenue-dependent items are ASSUMED if revenue targets haven’t been validated against pipeline data. The budget becomes a map of its own confidence levels.

Competitive Analysis: Every claim about a competitor’s strategy, pricing, or market position should be tagged. Public financial data is VERIFIED. Inferences from job postings or patent filings are PROJECTED. Assumptions about their future moves are ASSUMED — with an explicit “if wrong” note. This prevents the common scenario planning failure where competitive intelligence is a blend of hard data and conjecture, presented uniformly as fact.

The Framework as a Pattern

Looking across all three posts, the general framework can be stated in one paragraph:

When using AI in any domain where fidelity to sources matters, apply three rules: (1) give the model explicit permission to not-know, with labeled gaps; (2) make the cost of silent invention higher than the cost of flagged uncertainty; (3) require every claim to carry a provenance tag showing whether it comes from verified source material, from stated assumptions, or from the model’s own inference. The specific labels change by domain, but the structure is universal.

That bottom row is the portable version. It works for legal research, medical summarization, academic literature review, code refactoring, translation — any task where you need the model to be useful without being dishonest.

RAND’s James Dewar wrote in 2002 that every plan has a “ghost scenario” — the unstated set of assumptions about the future to which the plan is unconsciously suited. The three-rule framework is, in essence, a ghost-scenario detector. It forces the invisible to become visible, whether the plan is a vendor contract, a fictional universe, or a five-year business strategy.

The models are getting smarter every quarter. Making them honest is still up to us.

Sources and Further Reading

• Dewar, J.A. et al. (1993/2002): “Assumption-Based Planning.” RAND Corporation. The foundational methodology for identifying, testing, and planning around critical assumptions. Overview at MindTools.
• Lambdin, C. (2024): “Assumption-Based Planning.” Excellent deep-dive into ABP with the “ghost scenario” concept.
• Ramírez, R. et al. (December 2025): “A Faster Way to Build Future Scenarios.” MIT Sloan Management Review. On integrating generative AI into the Oxford Scenario Planning Approach.
• Schwartz, P. (1991): “The Art of the Long View: Planning for the Future in an Uncertain World.” The foundational text on corporate scenario planning.
• Previous posts in this series:
  ChatGPT and Claude Got Smarter. Not More Honest. — The original three rules for document extraction.
  From Contract Extraction to Alternate History — Adapting the rules for worldbuilding.

A few weeks ago I wrote about three prompt rules that stop AI from guessing when extracting data from documents. The rules — Force Blank, Penalize Guessing, Show the Source — were designed for mundane business problems: contracts with contradictory clauses, meeting notes with ambiguous commitments, invoices with missing fields.

But the more I used them, the more I noticed something: the same rules solve an entirely different problem — one that has nothing to do with business documents.

They solve worldbuilding.

The Problem: AI as a Continuity Editor

Anyone who has tried to use an LLM for sustained creative work knows the pattern. You’re building an alternate history, a fantasy setting, a science fiction universe, a tabletop RPG campaign. You’ve written hundreds of pages of lore. You hand it to Claude or ChatGPT and ask a question about how your fictional world works.

And the model invents something.

It creates a faction that doesn’t exist. It attributes a technology to the wrong era. It “remembers” a character who was never in your notes. It confidently places a fictional event in a real historical period and gets the real history wrong while doing so. The output sounds plausible, internally consistent, beautifully written — and it contradicts everything you’ve built.

This is the same structural problem I described in the earlier post, just in a different domain. The model is trained to produce complete, coherent output. When your lore has a gap, the model fills it — because filling gaps is what it was optimized to do. Whether the gap is “what are the payment terms in section 4” or “what happened in the Imperial Senate after the divergence point,” the instinct is identical: make something up that sounds right.

Researchers have a term for this in the fiction context: “character hallucination” (Wu et al., 2024) — when an AI playing a role violates the established identity of that role. The IJCAI 2025 tutorial on LLM role-playing calls the broader challenge “controlled hallucination”: the model must invent creatively within the established rules of a fictional world, while rigorously refusing to invent things that contradict those rules. The line between productive creativity and lore-breaking confabulation is exactly the line the three rules are designed to draw.

The Adaptation: Worldbuilding Has Two Canons, Not One

In contract extraction there’s one source of truth: the document. Extract what’s there, flag what isn’t, don’t invent.

In alternate history, there are two sources of truth operating simultaneously:

1. Real history — everything that happened in our world before the story diverges from it
2. Your lore — everything you’ve established about what happens after the divergence

Both are canonical. Both are places the AI must not invent. And the boundary between them is sharp: the “point of divergence” (POD), the moment at which your fictional timeline breaks from real history.

Before the POD, the AI must be a historian. It can reference real people, real technologies, real battles, real events — but only things that actually happened. Inventing a battle that didn’t happen or a person who didn’t exist is as bad as making up a contract clause.

After the POD, the AI must be a continuity editor. Only the things established in your lore exist. Everything else is a gap — and gaps should be labeled, not filled.

This is where the three rules come in, almost unchanged.

The Three Rules, Adapted

Rule 1: Force Blank → Label the Gaps

In document extraction, the model leaves a field BLANK when the data is missing and explains why. In worldbuilding, the same principle applies with two labels instead of one — because there are two types of gap:

• [HISTORICAL GAP] — for events before the point of divergence that the model isn’t certain about. Don’t invent a Roman consul’s biography; flag the gap.
• [LORE GAP: no established specification] — for developments after the point of divergence that your lore hasn’t addressed yet. Don’t invent a new faction, technology, or major event; flag the gap.

The crucial move is the same as before: give the model explicit permission to not-know. Without this permission, the model’s completion instinct will override its uncertainty detection, and you’ll get confidently-written hallucinations that feel like canon but aren’t.

Rule 2: Penalize Guessing → A False Invention Is Worse Than a Gap

The business version of this rule says: “A wrong answer is 3× worse than a blank. When in doubt, leave it blank.”

The worldbuilding version is even more forceful, because the consequences are worse. A wrong payment term on a spreadsheet gets corrected. A wrong lore detail, accepted into your canon because it sounded right, can poison hundreds of hours of subsequent writing. Every future reference builds on it. Every character interacts with it. By the time you catch it, it’s woven through your world.

So the rule becomes:

A false invention is worse than acknowledging a gap in the worldbuilding.

No multiplier needed. The asymmetry is total. In creative work, a gap is a prompt to expand your lore on your own terms. A bad invention is a bug that ships.

Rule 3: Show the Source → Three Provenance Tags Instead of Two

In document extraction, every value is either EXTRACTED (directly from the source) or INFERRED (calculated or derived). In worldbuilding, you need three tags because you have two canonical sources plus your own extrapolation:

• (HISTORY) — real historical fact from before the point of divergence
• (LORE-ESTABLISHED) — stated exactly this way in your source lore
• (LORE-INFERRED) — a logical consequence the model is drawing from your lore, with a one-sentence justification

The third tag is where the magic happens. You want the model to extrapolate — that’s what makes it useful for worldbuilding. An established technology must have consequences; an established faction must interact with other factions; an established event must have ripple effects. But you want those extrapolations flagged, so you can review them and decide whether they fit your vision. A flagged inference you disagree with takes thirty seconds to correct. An unflagged inference that quietly becomes canon takes hours to untangle three sessions later.

The Combined Prompt

Here is the full adaptation, structured as a system prompt you can paste into any long-running chat about your fictional world. Replace the bracketed placeholders with your own setting.

We are building an alternate timeline that begins in [YEAR] with [CHANGE / POINT OF DIVERGENCE]. You are my historian and continuity editor for this alternate-history universe. Your task is to produce texts, responses, and lore concepts that are absolutely free of contradiction.

The primary rule (the Point of Divergence): The year of divergence is [YEAR].

Rule 1 — BEFORE the Point of Divergence (strict history):
• Everything that happened before this date must correspond 100% to real, verifiable Earth history.
• Do not invent historical persons, technologies, battles, or events.
• If you are not certain of a historical detail, do not invent one. Use the placeholder [HISTORICAL GAP] instead.

Rule 2 — AFTER the Point of Divergence (strict lore canon):
• Everything that happens after this date must be based exclusively on lore texts I provide.
• Do not invent new factions, main characters, major events, or fundamental technologies that are not established in my texts.
• If asked about developments my lore does not specify, respond with [LORE GAP: no established specification]. A false invention is worse than acknowledging a gap in the worldbuilding.

Rule 3 — Source and logic labeling:
To keep the worldbuilding clean, mark in parentheses at the end of each paragraph or for each significant claim where the information comes from:
• (HISTORY) for real historical facts before the point of divergence
• (LORE-ESTABLISHED) for facts stated exactly this way in my texts
• (LORE-INFERRED) for logical conclusions drawn from my lore (e.g., how an established technology affects daily life). When inferring, briefly explain what you are drawing the inference from.

Plug in the year, plug in the divergence event, attach your lore documents, and you have a continuity editor that actively refuses to lie to you.

What This Enables

The workflow change is significant. Without these rules, every AI-generated paragraph needs to be cross-checked against both real history and your own notes — which nobody actually does, which means errors accumulate silently. With the rules, your attention goes exactly where it should: to the gaps (where you get to decide what your world does next) and to the inferences (where you get to approve or override the model’s extrapolation).

A few observations from applying this in practice:

The gaps are often the most interesting output. When the model flags [LORE GAP] for something, that’s the moment you realize your lore has a hole — and often, that hole is exactly the next thing you should develop. The model isn’t failing to answer; it’s telling you where your world needs more work.

Inferences reveal your lore’s implications. A well-labeled (LORE-INFERRED) paragraph often surfaces consequences you hadn’t thought through. “You established that faction X controls the trade route in Y; inferring, this would mean port city Z becomes economically dependent, which suggests tension with neighbor W.” That’s useful even if you reject the specific extrapolation — it shows you a logical consequence of your own setup.

Real history keeps the fiction grounded. Alternate history works best when the “before” is accurate. If your timeline diverges in 1914 and the model gets the pre-1914 world wrong, the whole divergence loses meaning. Forcing (HISTORY) labels — and forcing the model to flag [HISTORICAL GAP] when it’s uncertain — keeps the foundation solid.

The Deeper Pattern

What I find striking is that the same three rules work across two domains that seem to have nothing in common. Business document extraction and creative worldbuilding share no vocabulary, no audience, no workflow. But they share a structure: in both cases, the user needs the AI to distinguish between what is established and what is invented, and to flag the boundary clearly.

That structural similarity is worth taking seriously. It suggests the three rules aren’t really about contracts or fiction specifically — they’re about the general problem of using AI in any context where fidelity to a source matters more than fluency of output. Legal research. Code refactoring against a style guide. Historical research. Medical summarization. Translation against a glossary. Technical writing against a spec. Academic literature review.

In each of these, the AI’s default behavior — produce a confident, complete, coherent answer — works against the user’s actual need, which is to know which parts of the output are grounded and which are the model’s own contribution. Force Blank gives it permission to not-know. Penalize Guessing changes the calculus in favor of honesty. Show the Source makes the boundary between source and invention visible.

Three rules. Two sentences each. Apply everywhere fidelity matters.

The alternate history version is just one adaptation. I’d be curious what other domains this pattern fits — if you find one, I’d love to hear about it.

Sources and Further Reading

• Wu et al. (2024): “RoleBreak: Character Hallucination as a Jailbreak Attack in Role-Playing Systems.” Paper defining character hallucination as violation of role identity.
• IJCAI 2025 Tutorial: “LLM-based Role-Playing from the Perspective of Hallucinations.” Introduces the concept of “controlled hallucination” — creative invention constrained by scenario-specific rules.
• Previous post: “ChatGPT and Claude Got Smarter. Not More Honest.” The original three rules for document extraction.
• Panickssery, N. (2025): “Why do LLMs hallucinate?” On why hallucination is the default behavior of base models and requires active training or prompting to suppress.
• Bicking, I. (2023–2025): “Creating Worlds with LLMs.” Series of essays on worldbuilding with LLMs, including the tension between consistency and surprise.
• DiGRA (2025): “Reconceptualizing LLM-Induced Hallucinations as Game Design Features.” On when hallucinations enhance versus break i