Verify before you trust the answer

The problem

You named the outcome and gave a clean brief. The answer comes back fast, well formatted, and sure of itself. So you use it.

That's the step where most of the damage happens. Models write in the same confident tone whether they're right or guessing. A number that was never in your data reads exactly like one that was. A step that got skipped leaves no gap on the page. And on a long task, one early mistake quietly carries through everything after it, so by the end you're reviewing a polished answer built on a bad assumption.

Reading the output carefully doesn't fix this. You can't spot what isn't shown.

The technique

Make checking part of the request, not something you hope to do afterward. Two moves do most of the work.

First, ask for evidence alongside the answer: where each claim came from, what was assumed, and what the model could not confirm.

Second, for anything complex, don't ask for the finished thing in one pass. Run it in five stages: Define, Prepare, Execute, Verify, Improve. Stop after each one and look before moving on.

Copy-ready prompt:

Work in stages and stop after each one for my review.

1. Define: restate the goal, the success criteria, and what's out of scope.
2. Prepare: list the inputs you'll use and any assumptions you're making.
3. Execute: produce the work.
4. Verify: check the result against the success criteria. For each claim or number, say where it came from. Flag anything you assumed or couldn't confirm.
5. Improve: list the weakest parts and how you'd fix them.

What this looks like

Before:

Analyze last quarter's sales data and tell me which region is underperforming.

After:

Analyze last quarter's sales data to find the underperforming region. Work in stages. In Define, tell me how you'll measure underperforming. In Verify, show the actual figures behind your conclusion, name the columns you used, and flag any rows you excluded or numbers you estimated.

The first version gets you a region name and a tidy explanation. The second one shows its work. Often the Define step alone catches the problem, like the model planning to compare raw revenue when one region has half the stores. That gets fixed before any analysis runs, not after you've repeated the conclusion in a meeting.

Limits

A model checking itself is better than no check, but it isn't proof. It can confirm a wrong number against a wrong assumption. Anything that matters still needs a check you can make yourself: open the source, rerun the calculation, or compare against a figure you already trust. Stages also cost time, so skip them for quick, low-stakes asks. Reusable playbooks and when to productize a workflow come later in this series.

Try it

Pick a recent answer you used without checking. Run the same task again with the five-stage prompt, and read the Verify section first. Count how many claims came with a source and how many were flagged as assumptions.