How to Check Without Losing the Point

An answer arrives: two pages, well-organised, plausible throughout. Now what? Reading it critically end to end takes almost as long as writing it yourself, which cancels the entire benefit. Skipping the check works until the day it doesn't.

Most people resolve this by feel, which means they check the things that happen to catch their eye and trust everything smooth. There's a better method, and it takes about thirty seconds.

An answer is not one claim

Here's the move the whole article rests on.

A two-page answer feels like a single object you either trust or don't. It isn't. It's a bundle of a few dozen statements with wildly different risk profiles: general reasoning that you can evaluate yourself as you read, structure that's either useful or not, and then a small number of hard, specific atoms — a figure, a date, a name, a citation, a function parameter, a claim of causation.

Almost all the risk is concentrated in those atoms, and there are usually five to ten of them.

Don't check the answer. Check its checkable points.

That turns a vague, exhausting task into a concrete, quick one: pull out the specifics, verify those, and read the rest for sense the way you'd read a colleague's memo.

The atoms worth extracting, in rough order of danger: numbers and statistics; dates; names of people, products, laws, cases; verbatim quotations; links, references and file paths; API details, parameters, versions, commands; superlatives and absolutes ("the only", "always", "the best"); and causal claims ("because", "which leads to"). Anything else in the text is either checkable by ordinary reading or not checkable at all.

The ladder, cheapest first

Read as an expert, if you are one. In your own field this is nearly free — errors jump out. In a field you don't know, the same reading gives you nothing, and no amount of care changes that. Which is the previous article's rule again: don't delegate what you can't evaluate.

Probe the ground. Before trusting the model on an unfamiliar topic, spend one question establishing whether the terrain is thick or thin: ask about something in that area that doesn't exist — an invented term, a plausible-sounding book, a made-up regulation. If it confidently elaborates, you've learned that this topic is thin ground today, and everything else in the conversation deserves more suspicion. Thirty seconds, and it recalibrates the whole session.

Demand traceability. When the answer is based on material you supplied: "for every claim, quote the exact sentence from the source; if there's no such sentence, write 'not in the source'." This converts verification into comparison — you check quotes against the document instead of judging claims out of thin air.

Run it twice on a clean desk. Ask the same question in a new chat and compare. Divergence on a specific atom is a strong signal that the ground there is thin. Convergence proves less than it feels like — both runs can roll into the same well-worn wrong valley — but as a cheap filter it's excellent.

Derive it backwards. "Show the path from the data to this conclusion, step by step." Reconstructed reasoning is checkable in a way that a finished verdict is not, and gaps in it tend to be visible even to a non-expert.

Attach an external signal. Run the code. Open the link. Recompute the number in a spreadsheet. Search for the case. This is real verification; everything above it is triage that tells you where to spend it.

Ask a human for the expensive, irreversible, or specialised.

What isn't verification

Worth listing plainly, because all of these feel like checking:

Asking the same model "are you sure?" — that's sycophancy bait, not a check.
Asking for a source without opening it. An unfollowed citation is decoration.
Re-asking in the same chat: the first answer is on the desk and pulls the second one toward it.
Confident tone, tidy formatting, hedged language, a stated confidence percentage. All of these are output style, and none correlate reliably with being right.

The general principle from article 4 holds: a check that stays inside the loop isn't a check.

The trap is older than AI

The instinct to under-verify isn't a failure of character, and it isn't new. Psychologists studying pilots and operators named it automation bias back in the 1990s: people supervising an automated system accept its output more readily than they'd accept the same claim from a person, and — the sharper finding — they stop noticing errors they would otherwise have caught unaided. Linda Skitka's group demonstrated both effects experimentally; Raja Parasuraman and Victor Riley mapped the whole space in 1997 as use, misuse, disuse, abuse.

Two things follow. The tendency is normal and needs a habit rather than willpower — which is what this ladder is. And the risk is highest exactly where the system is usually right: after the twentieth correct answer, checking the twenty-first feels absurd. That feeling is the bias, not evidence.

Don't over-verify either

The opposite failure is real and more common among careful people. If you interrogate everything, you've hired an assistant and become their full-time auditor. The savings are gone and so is the reason to use the tool.

Sort by cost of error, exactly as in article 4. Brainstorms, drafts, explanations you'll test in practice anyway, code you're about to run — don't verify, just work; errors surface naturally and cost seconds. Numbers in a document, citations you publish, anything legal, medical or financial, anything irreversible, anything a client sees — verify every atom, every time.

And notice which side of that line most of your work actually sits on. For most people it's the cheap side, which means the correct amount of verification for most of their AI use is close to zero — and the whole discipline exists for the small remainder.

One bonus, straight from How to Learn: when you verify by reconstructing the reasoning yourself, you're doing retrieval practice on the material. Checking a good explanation is one of the few kinds of double-spend that actually pays — you get the answer and you get the learning.

In practice

Extract the atoms first. Numbers, dates, names, quotes, links, parameters, absolutes, causal claims. Five to ten per answer, and that's your check list.

Probe an unfamiliar field before trusting it. Ask about something that doesn't exist.

Make it quote the source whenever the answer is built on material you supplied.

Compare two clean runs when the stakes are moderate and the topic is narrow.

Never verify inside the same conversation. Outside signal or nothing.

Decide by cost of error, and accept that most work needs no check at all.

Check yourself

Close the article and answer in your own words:

Why is "is this answer trustworthy?" the wrong question, and what replaces it?
Which atoms carry almost all the risk, and roughly how many are there in a typical answer?
How does the "probe the ground" trick work, and what exactly does it tell you?
What does demanding exact quotes change about the nature of the check?
What does a divergence between two clean runs mean — and what does a convergence not mean?
What is automation bias, and why does the risk peak after a long run of correct answers?
What's the cost of over-verification, and how do you decide where to spend?

In short

An answer is a bundle: mostly readable reasoning plus five to ten hard atoms — numbers, dates, names, quotes, links, parameters, absolutes, causal claims. The risk lives in the atoms.
Ladder, cheapest first: expert reading, probing the ground with something that doesn't exist, demanding exact quotes, comparing two clean runs, deriving backwards, then a real external signal.
Not verification: "are you sure?", unopened sources, re-asking in the same chat, confident tone or formatting.
Automation bias (Skitka et al.; Parasuraman & Riley, 1997) is decades older than AI: supervisors of automation under-check, and stop catching errors they'd otherwise see. Needs a habit, not willpower.
Risk peaks after a long streak of correct answers, precisely when checking feels most absurd.
Over-verification cancels the tool. Sort by cost of error, and accept that most everyday work needs no check.
Verifying by reconstructing the reasoning doubles as retrieval practice.
Don't check the answer. Check its checkable points.