x
Ask for the working, not just the answer. One line, added to the end of any prompt:
"For each factual claim, mark it as either: something you're confident about, something you're inferring, or something you'd need to look up. Put the source next to anything checkable."
That's it. What comes back is no longer a smooth block of prose you have to trust or rewrite. It's a document with seams — and seams are where checking happens.
Because "be accurate" asks for an outcome, and this asks for a structure.
Fluent output is uniform by default. A sentence the model is certain about and a sentence it invented look identical: same confident register, same clean grammar, same absence of hedging. That uniformity is the actual problem. It isn't that AI output is unreliable — plenty of it is fine — it's that the reliable and unreliable parts are indistinguishable, so verifying any of it means verifying all of it, which costs more than writing it yourself.
Asking for the labelling breaks the uniformity. Now the four claims marked inferring are your ninety seconds of work, and the rest can be read normally. You've converted an unreviewable artefact into a reviewable one, which is a different thing from making it more accurate.
Worth being honest about the limits: a model's self-reported confidence is not a measurement. It's a useful sorting signal, not a guarantee — things land in the wrong bucket. But a rough sort beats no sort, and the failure mode is "you check something that turned out to be fine," which costs seconds.
Anywhere a wrong detail is expensive and a slow read is worse.
Client-facing documents. A proposal with an invented specification is worse than no proposal. Label the claims, check the four that matter, send with confidence. This is the step that makes the fifteen-minute client report safe to actually send rather than merely fast to produce.
Anything with a number in it. Numbers are where fluency is most dangerous, because a plausible figure reads exactly like a correct one and nobody squints at a decimal in a tidy sentence.
Research summaries. Especially about anything recent. The gap between what a model knows and what happened last month is precisely the gap the "you'd need to look up" bucket exposes.
Anything you'll be held to. If your name is on it, the labelling is the cheapest insurance available.
Confident — read normally, spot-check one at random. If the random check fails, you've learned something important about the whole document.
Inferring — this is the valuable bucket, and usually the smallest. These are the claims that sound like knowledge and are actually reasoning. Verify or cut. Most of the time you'll cut, and the piece gets better.
Look it up — either look it up or delete the sentence. The one thing not to do is leave it in because it reads well. A sentence you haven't verified is a liability with good manners, which is Sunday's argument in advance.
Do this for a fortnight and something more useful than accurate documents happens: you start to see where your particular workflow generates soft claims. For some people it's always dates. For others it's always attribution — who said the thing, which client asked for it. For most it's numbers.
Once you know your pattern, you can build the check into the prompt permanently rather than remembering to add it, which is the point of the one-pager that doubles every AI answer. The line stops being a technique and becomes part of the setup — and the version you don't have to remember is the only version that survives a busy week.
This is verify in the vet → disclose → verify sequence, made concrete. It isn't a principle you agree with; it's a line you paste.
Take something you were about to send, run it back with the line attached, and see how many claims land in the middle bucket. The number is usually higher than expected, and that's the useful part.
For the full prompt set, the free 5-min read is here: 7 AI Prompts That Run a One-Person Business.
Related Decodes
TL;DR: Add one line to any prompt — ask it to mark each factual claim as confident, inferred, or needs-looking-up, with sources next to anything checkable. This works where "be accurate" fails because it asks for structure rather than an outcome: fluent output is uniform, so reliable and invented sentences look identical until something breaks them apart. Check the inferred bucket, cut or verify the look-up bucket, and after a fortnight build the line permanently into your setup.
