Prompt Engineering 10 min read Updated Jul 9, 2026

How to Make AI Separate Facts, Assumptions, and Recommendations

Ask AI to analyze something and it hands back one smooth paragraph where you can't tell what you told it from what it assumed from what it's recommending. Here's how to make it split the answer into visible layers — facts, assumptions, inferences, recommendations, and what still needs checking.

Build a Layered Analysis Prompt

When the answer blends what you said with what the model guessed

You paste a client note and ask the AI to summarize it and recommend next steps, and back comes a confident paragraph: "The client needs a CSV export for their monthly reports, so build a CSV export feature next sprint." It reads like a briefing. But look closely and you can't tell the parts apart: the client never said "CSV," never gave a deadline, and "needs export" is half something they told you and half something the model worked out. Facts you provided, guesses the model made, and advice it's giving are all written in the same flat, assured voice — so you can't see which pieces to trust and which to check.

That blending is the problem this guide is about. When an answer runs everything together, an assumption reads exactly like a fact, an inference reads like a source-backed conclusion, and a recommendation reads like a settled decision. The fix isn't to make the model more careful in general — it's to make it show its layers: separate the facts you gave it from the facts a source contains, from the assumptions it made, from the inferences it drew, from what it recommends, from what nobody knows yet. A layered answer makes the reasoning visible and tells you exactly where to look before you act. One thing it does not do is make the facts true or the assumptions safe — separating a claim is not verifying it, and the labels are the model's, so you still decide whether they're right.

Why the model runs it all together

A model is trained to produce fluent, confident prose, and fluent prose hides its seams. "You told me X, I'm assuming Y, so I'd guess Z, therefore do W" is four different kinds of claim, but the smooth version — "you should do W" — reads better and sounds more authoritative, so that's what you get by default. The distinctions that matter to you are exactly the ones that get sanded off in the name of a clean answer. Here's what disappears when the layers collapse:

  • Assumptions pass as facts. "CSV" was a guess the model made to keep moving, but written plainly it looks like something the client specified.
  • Inferences pass as evidence. "The workflow has friction" is a reasonable read of "copy/paste is slow," but stated as a conclusion it sounds like a measured finding.
  • Recommendations pass as decisions. "Build it next sprint" is advice resting on unconfirmed scope, but phrased as a next step it sounds like the call has been made.
  • Unknowns vanish. The file format, the permissions, the deadline — none were provided, but a confident paragraph fills the silence instead of naming it.
  • "Likely" sounds measured. Words like probably and high-confidence read as if a probability was computed, when they're just the model's self-rated caution.

Step 1: Give the answer named layers

Stop asking for "an analysis" and ask for the answer split into labeled sections it can't merge: Facts provided (what you gave it), Facts from source (what a document actually says, if there's a source), Assumptions, Inferences, Recommendations, Unknowns, and What to verify before acting. When each claim type has to live under its own heading, the model can't quietly file a guess next to a fact — it has to decide which layer each sentence belongs in, which is the whole point.

The Markdown Output Builder is built for pinning exactly this shape: you define those sections in order, each with a note on what belongs in it, and its strict mode instructs the model to use every heading, keep the order, and never merge or drop one. The Research Brief Prompt is a smaller, working version of the idea — it splits Findings from Recommendations into separate pinned sections with the rule stated outright ("separate what was found from what is recommended; different sections, different claims") and asks for the evidence behind each finding. It only covers three of the layers, but it shows the move: the seam between what is known and what is advised becomes a formatting requirement, not a hope. The tool builds the skeleton; the model fills it when you run the prompt in your own assistant, and whether each item landed in the right layer is still yours to check.

Step 2: Separate what you were told from what the model worked out

The most important seam is between a fact and an inference. "The client said the copy/paste process is slow" is a fact — it's traceable to something you provided. "The workflow has friction worth removing" is an inference — it's the model's leap from that fact, and it might be right or might be over-reading. Make the prompt keep them apart in wording, not just in sections: a fact should be attributable ("the note says…"), an inference should be marked as one ("this suggests…"), and neither should borrow the other's certainty.

This labeling discipline already exists in NewPrompt, worked out in a specific domain. The Error Analysis Prompt — built for debugging a runtime exception — carries an evidence rule that tags every statement as a FACT (directly observed), an ASSUMPTION (believed without evidence, which "must be verified or discarded — never silently promoted to facts"), or a HYPOTHESIS (a testable claim that ships with its test). It's engineering-scoped, but the mechanic ports straight across: the value is the rule that a guess can never wear a fact's clothes. Borrow that discipline, not the debugging specifics — your analysis needs the same refusal to let an inference quietly become evidence.

Step 3: Make every assumption carry its weight

A bare list of assumptions is better than none, but an assumption is only useful if you can act on it. So ask for each one to carry four things: the assumption itself, why it was needed (what gap forced it), what would change if it turned out false, and how to confirm it. "Assumed CSV is acceptable — needed because format wasn't specified; if false, the whole build target changes; confirm by asking the client" tells you what the guess costs and how to close it. A plain "assumed CSV" tells you nothing you can do.

This is where a layered answer earns its keep. The unknowns you can see are cheap; the ones buried in a confident recommendation are expensive, because you find them after you've built on them. Writing the assumption down with its blast radius — what breaks if it's wrong — turns it from a hidden dependency into a visible decision you can check before it matters. And be honest about what the label buys you: an assumption marked and explained is one you know to verify, not one that's been made safe. The point of surfacing it is that you go check it, not that you can now skip checking.

Step 4: Attach the caveats to the recommendation, not a footnote

A recommendation that arrives clean, with its conditions stripped off, is the most dangerous line in the answer — it's the one you're most likely to act on. So require the recommendation to travel with its caveats attached: what it depends on, which assumptions it rests on, the risk if one of those assumptions is false, and what to verify first. "Scope a CSV-only v1 — depends on CSV being acceptable and permissions being simple; risk if the client needs formatted reports; verify format and roles first" is a recommendation you can weigh. "Build CSV export next sprint" is one you can only obey or ignore.

The framing to hold onto is that the recommendation is an input to your decision, not the decision. The model can lay out what it would do and why, but it doesn't know the things you didn't tell it, and it can't be accountable for the outcome. Keeping the depends-on and the risk welded to the recommendation is what keeps it in its place — a well-reasoned suggestion with its conditions showing, rather than a verdict you have to unpack after the fact to find out what it assumed.

Step 5: Keep "confident" honest — and check the layers actually hold

Confidence language is where a layered answer can still mislead. "High confidence" and "90% likely" read as if a probability was measured, but a model writing them is self-rating its own caution, not computing a number — and a confident wrong answer is exactly the failure honest confidence language is meant to guard against. So instruct the model to say why it's confident instead of just how much: the strength of the evidence, the reason for the doubt, what would raise or lower the certainty. "Confident because the note states this directly" is useful; "confidence: high" is a vibe. The Data Analyst Role Prompt is a good model of the habit — it's built to "present uncertainty honestly instead of laundering it into false precision" and to treat a correlation as a hypothesis rather than a conclusion, which is the same discipline of not letting a soft signal harden into a stated fact.

Once the answer comes back layered, you can check that the structure actually held. Point the AI Output Validator at it with the expected sections listed, and it will confirm each layer is present, in order, and not left blank, and hand you a repair prompt for any that are missing or empty. Be exact about its limit, because this is the guide's whole boundary in miniature: it checks that the shape is complete, not that the content is filed correctly. An inference mistakenly placed under Facts passes its check — a structural scan can't tell a mislabeled claim from a right one, and it verifies none of the facts. The validator confirms the layers exist; deciding whether each claim is in the right layer, and whether the facts are actually true, stays your job.

Common mistakes

The ways a layered answer slips back into a blended one:

  • Asking for "the analysis" and hoping. Without named layers the model defaults to one smooth voice; you have to ask for the sections by name.
  • Listing assumptions without their weight. "Assumed CSV" with no why, no if-false, and no how-to-confirm is a label you can't act on.
  • Reading a label as a guarantee. A "fact" tag marks a claim's origin, not its truth; separating claims is not verifying them.
  • Treating "high confidence" as a probability. It's the model's self-rated caution in words, not a measured number — ask why it's confident, not just how much.
  • Letting the recommendation shed its caveats. A recommendation without its depends-on and risk is the line you'll act on blind.
  • Trusting a structure check to catch mislabeling. A validator confirms the sections are present; it can't tell that an inference got filed under Facts — that read is still yours.

A worked example: the client note

Take a short client note and watch the difference between an answer that blends everything and one that shows its layers.

One client note answered as a blended paragraph vs. split into facts, assumptions, inferences, unknowns, and a caveated recommendation 
THE INPUT (a client note):
  - They asked whether the dashboard export can include filtered data.
  - They mentioned monthly reporting.
  - They said the current manual copy/paste process takes too long.
  - They did NOT mention file format, permissions, or a deadline.

THE BLENDED ANSWER (facts, guesses, and advice in one breath):
  "The client needs a CSV export for their monthly reports, so you should
   build a CSV export feature next sprint."
  what's hidden in that one sentence: "CSV" is an assumption, "needs export"
  mixes a fact with an inference, "next sprint" is a recommendation with no
  deadline behind it, and format / permissions / urgency were never stated.

THE SAME ANSWER, LAYERED:
  Facts provided:
    - client asked about dashboard export with filtered data
    - monthly reporting was mentioned
    - the current manual copy/paste process is slow (their words)
  Assumptions:
    - "export" means a downloadable file   (why: not specified | confirm: ask)
    - CSV may be enough                     (why: no format given | confirm: ask)
    - monthly reporting is the main use     (why: only use mentioned | confirm: ask)
  Inferences:
    - the current workflow has friction worth removing
    - an export could cut the manual effort
  Unknowns:
    - file format, permissions, deadline, sensitive fields, dataset size
  Recommendation:
    - do NOT commit to a CSV-only build yet
    - first confirm format, permissions, and the real reporting need
    - if CSV is acceptable and permissions are simple, scope a CSV-only v1
  Verify before acting:
    - confirm format | confirm who may export | confirm sensitive fields | confirm deadline

Where this fits in NewPrompt

The layered answer is a shape you author once and reuse. The Markdown Output Builder is where you pin the sections; the AI Output Validator is where you check they came back intact; and the discipline itself shows up already worked out in NewPrompt's prompts across different domains — a research brief that walls Findings off from Recommendations, an error-analysis prompt that tags every line FACT, ASSUMPTION, or HYPOTHESIS, a data-analyst persona that refuses to launder uncertainty into precision. None of them is the whole seven-layer structure; together they're proof the move is real, and the guide's job is to generalize it to any analysis you ask for. If you want it on every answer rather than one, the same layer rules go into a system prompt you set once, so the assistant separates its claims by default.

What none of this does is close the gap between a labeled claim and a true one — worth being blunt about, because the labels are seductive. Separating facts from assumptions makes the reasoning visible; it doesn't verify a single fact. A "confidence" line is the model's caution, not a probability. The validator confirms the sections exist, not that the claims are sorted right. And the recommendation, however well its caveats are attached, is input to your decision, not the decision. It's also worth separating from its neighbors: this is about labeling the claim types inside one answer, not stopping the model from inventing data it doesn't have, not checking its claims against a source document, and not comparing options before it recommends one — those are their own jobs. Here the work is simpler and comes first: make the answer show you which parts are solid ground and which are the model thinking out loud, so you know where to stand and where to check.

Tools for this guide

Each generates the prompt described above — you run it in your own AI assistant.

Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output
Tool

AI Output Validator

Paste an AI's output and validate it against the expected format — with a repair prompt for every failure found.

Structured Output

Ready-made resources

Reusable prompts and templates for the exact steps in this guide.

Resource

Research Brief Prompt

Objective, Background, Findings, Recommendations, Open Questions — briefs where what was found and what to do stay clearly separated.

Research
Resource

Error Analysis Prompt

An exception is a symptom, not a diagnosis: trace from the throw site back to the root trigger, with the runtime checklist on the table.

Engineering
Resource

Data Analyst Role Prompt

A data analyst role prompt with statistical honesty built in — clarify the decision first, treat correlation as a hypothesis, and never launder uncertainty into precision.

Research

FAQ

If the model labels something a "fact," does that mean it's verified or true?

No — and this is the distinction that matters most. A "fact" label answers a different question than "is this true?" It says where the claim came from — you provided it, or a source states it — not that it's correct. The model can also misfile: an inference it's confident about can end up under Facts, and nothing about the label catches that. Separating claims by type makes the reasoning inspectable, which is genuinely useful, but it's a map of where things came from, not a verification of any of them. The checking is still yours to do; the layers just tell you what to check and where.

Isn't "confidence: high" the model telling me how likely something is?

Not in the way it reads. When a model writes "high confidence" or "90% likely," it's producing words that describe caution, not a probability it measured — there's no calibrated number under the phrase. Treat "high confidence" as "the model isn't flagging this one to double-check," which is a weaker and more honest claim than a percentage implies. That's why it's worth asking the model to say why it's confident — evidence is stated directly, or the doubt has a named reason — instead of just how much. A reason you can evaluate; a confidence score you can only take on faith.

If the model separates out its assumptions, can I trust the rest and skip checking it?

No — an assumptions section tells you where to look, not what's safe to ignore. The value of surfacing an assumption is that you go confirm it, and the value of the other layers is that you can see what each claim rests on — but a clean-looking Facts section can still contain a misfiled inference or a fact the source got wrong. So the layers change how you review, not whether you review — they point you at the load-bearing assumptions and the shakiest claims first, instead of leaving you to find them in a wall of confident prose.

How is this different from making AI not invent data, or checking its answer against a source?

Different jobs at different moments. Making the model not invent missing data is about what it should refuse to do — say "not provided" instead of fabricating a value. Checking an answer against a source is verification done after the fact — comparing each claim to a document to see if it holds. This guide is upstream of both: it's about the shape of one answer, laid out so you can see which parts are facts, which are the model's assumptions and inferences, and which is a recommendation — no source required. Once an answer is layered, you know which claims are worth running the invent-check or the source-check against. The separation comes first; it's what makes the later verification targeted instead of a re-read of everything.