How to stop AI from making things up: give it the answer, then check it.

Every guide to this problem starts with a prompt, which is why so many people conclude it is unsolvable. A prompt changes the shape of the answer; it cannot give the model knowledge it lacks, and it cannot give it a mechanism to detect its own errors.

Asking a model to be accurate is like asking a confident witness to be careful. The tone improves and the facts do not. You need a different arrangement of the work, not a stronger adjective in the instruction.

The arrangement that works has three parts: the source material is supplied rather than remembered, the task is narrow enough that invention has nowhere to hide, and the output is checked against the source by someone who is not the model.

The single largest reduction available comes from pasting or attaching the material the answer must be based on. A specification, a policy document, a transcript, a spreadsheet, a page you already trust.

Then make the constraint explicit: answer only from the material above, quote the sentence each point comes from, and list anything the material does not cover as a gap rather than filling it in.

Grounding changes the failure mode from invention to misreading. Misreading is cheaper to catch, because the source sits next to the output and a human can compare them directly instead of searching the world for a fact that may not exist.

Most invention happens because the model is optimising for a complete-looking answer. Remove that pressure by asking for the gap explicitly: what is missing, what would need to be checked, what the source does not say.

A prompt that requests an unknown section gets you a shorter answer and a shorter review. A prompt that requests a complete answer gets you a complete answer, whether or not the material supports it.

In practice, ask for two lists: supported statements, and statements that need a source you have not supplied. The second list is the most valuable output in the session, because it is your to-do list.

One long prompt asking for a researched article invites a long chain of guesses. The same work split into extraction, outline, drafting per section and a separate audit pass keeps each step close to verifiable material.

The split matters because errors are easier to locate than to prevent. If the numbers come from a step where you supplied a table, you know exactly which part of the output to check.

Keep one pass separate and purely adversarial: ask for everything in the draft that is not supported by the source, with the sentence quoted. Models are reasonably good at this specific task, and a second pair of eyes that never gets tired is worth ten minutes.

Ask for short direct quotations with the location of each, then open every one. A quote that can be matched word for word against a page you can load is evidence; a paraphrase with a link attached is not.

This is the cheapest hallucination filter there is. Fabricated quotes fail immediately, misattributed quotes fail during the match, and real quotes at least establish that the source exists.

For anything that will be published, keep the links in the draft file. A reviewer who can click through in thirty seconds will do the check; one who has to hunt for a citation will trust it instead.

Names first, because an invented company or product undermines everything around it. Then numbers, then dates and versions, then quotations, then causal claims.

The order is not arbitrary. Names are quick to verify with one search. Numbers need a primary source. Causal claims are the slowest, and they are also the ones most likely to be technically true and practically misleading.

Give yourself a stopping rule: if two specifics in a paragraph cannot be verified in five minutes, cut the paragraph. Rebuilding it later from real material is faster than defending it.

Prices, plan limits, API names, legal thresholds, availability by country and organisational roles all change, and a draft produced from training data will describe an older world with total confidence.

Fix it structurally: every volatile claim gets the source and the date it was true. Not a vague soon, not a hedged currently, but a date and a link.

For technical documentation, pin versions. A command that worked in one release and not the next is worse than no command, because it produces a support ticket with the documentation quoted in it.

Where you need a fact and have no primary source, asking a second system is better than asking the same one twice, because a shared blind spot is less likely than a single one.

Disagreement between two models is a strong signal that the claim needs a real source, and agreement is weak evidence that it does not, since both were trained on largely the same material.

Treat both outputs as leads rather than answers. The finish line is a document you opened, not a model you trusted twice.

Keep a short log of every invented fact you catch: what was asked, what came back, what the truth was. Twenty entries will teach you more about your own risk profile than any published benchmark.

The log usually reveals a pattern: one kind of question, one niche, one client context where the drafts go wrong. That pattern becomes a prompt instruction, a review step, or a decision to stop using a model for that class of work.

It also gives you something to show a client or a regulator. A process with recorded catches is a different object from a promise to be careful.

If the work is a citation, a legal requirement, a dosage, a safety limit or a figure that moves money, generate the prose if it helps and write the fact yourself from the source. No workflow makes a guess safe in those places.

If the topic is too new for the training data, the model is a writing assistant only. If the topic is niche enough that you are the expert in the room, it is faster to write from your own notes than to check its version of your own field.

Accuracy is a design decision, not a model feature. Decide which claims must never be wrong, then arrange the work so that a machine never supplies them unchecked.