Make it show its work

The scheduling problem

When should we hold the team call? People are in Lagos, Berlin and Manila. Everyone works 9 to 6 local time.

You will often get a confident answer that does not survive checking. Manila is seven hours ahead of Lagos; the overlap is narrow and easy to get wrong in one pass.

Now ask for the steps:

First convert each person's 9 to 6 into UTC and show the three ranges. Then list every UTC hour where all three overlap. Then pick one and say why. If there is no hour where all three overlap, say so rather than choosing the least bad option.

This is usually right, and more importantly you can see where it went wrong when it is not. If the Berlin conversion is off by an hour, you can spot that in two seconds. The single-answer version gives you nothing to check.

Why intermediate steps help

For tasks with several dependent stages — conversions, comparisons against a list of constraints, multi-step arithmetic, working through a document clause by clause — writing the steps out genuinely improves accuracy. The intermediate text is where the work gets done. Skip it and you are asking for the last line of a calculation that was never performed.

It helps much less for recall, tone, translation, or summarising a short passage. There, asking for steps mostly makes the answer longer. "Think step by step" is not a universal upgrade, and adding it everywhere is a habit worth dropping.

A lot of newer products do this reasoning internally before answering, so you may not need to ask at all. What you can still ask for is the part you want to inspect: "list the constraints you are checking against, then answer."

The caveat that matters most

The steps a model shows you are not a log of how it produced the answer. They are text generated alongside the answer, in the shape of an explanation.

This is well studied and the finding is uncomfortable: models sometimes reach the right answer through stated steps containing an error, and sometimes produce flawless-looking reasoning to a wrong conclusion. The written reasoning can also be shaped by hints in your prompt that never get mentioned in the steps.

So do not treat shown reasoning as proof. Treat it as material you can check. Its value is that it puts intermediate claims where your eyes can reach them — the UTC conversions, the clause it thinks says X, the figure it took from the table. Those are checkable in seconds, and checking them is the point.

A wrong step under a right answer is not a paradox to explain away. It means both need looking at.

Give it permission to fail

Notice the last line of the good prompt: *if there is no hour where all three overlap, say so rather than choosing the least bad option.*

Without that, a model will usually produce an answer, because producing an answer is what the shape of the conversation calls for. Naming the escape route makes "there is no valid answer" an available response instead of a conversational failure.

Use this constantly:

• "If the contract does not cover this, say so."
• "If none of these three candidates meets the requirement, say none."
• "If you need a fact I have not given you, ask me instead of assuming."

That last one turns a guess into a question, which is nearly always the better trade.

What to ask for in practice

For a task with constraints: "list the constraints, then check each option against each constraint, then conclude."

For a document task: "quote the sentence you are relying on, then interpret it." A quote is verifiable. An interpretation on its own is not.

For anything numerical: "show the numbers you used and where each came from."

All three convert an opinion you have to trust into work you can audit.