Format is part of the request, not a garnish
You ask a model to compare three health insurance plans. Back comes nine paragraphs of thoughtful prose. Every fact you needed is somewhere in there, and you now have to do the comparison yourself with a highlighter.
The model did not fail. You did not say what you needed to walk away with.
Before:
Compare these three health insurance plans.
After:
Compare these three plans in a table. Columns: plan name, monthly premium in rupees, annual deductible, whether maternity is covered, whether my existing thyroid condition is excluded and for how long. One row per plan. If a document does not state something, write "not stated" — do not infer it. After the table, one single line: which plan is cheapest for someone who sees a doctor twice a year.
That is the same question with a usable shape, an explicit fallback for missing data, and a limit on the commentary.
Three format instructions worth remembering
Say the container. A table with named columns. A numbered list of exactly five. JSON with these keys. A WhatsApp message under 300 characters. A bulleted agenda. A diff.
Say what to leave out. This is badly underused. "No preamble. Do not restate the question. No summary paragraph at the end." Models open and close with padding by habit; you can simply switch it off.
Say what to do with gaps. "Write 'not stated' rather than inferring." Without that instruction, a missing figure gets a plausible one, and a plausible figure is much harder to catch than a blank.
Format quietly changes the thinking
Ask for a table and you force comparable claims. Every cell has to be filled with something about that plan, so vagueness has nowhere to sit. Ask for prose and you will get hedging, because prose has room for it.
This cuts both ways, which is where people get caught.
The honest caveat: rigid shapes can cost you
Suppose you ask for strict JSON, one object per contract, each with a risk_score from 1 to 10, and nothing else. Twenty contracts, twenty numbers, no words. The scores come back looking arbitrary, and they probably are.
Here is why. The text a model produces is where the work happens. A bare number has almost no text behind it, so there is nowhere for the reasoning to occur. You asked for the conclusion with the thinking removed.
The fix is not to abandon the format. It is to make room:
For each contract, write one sentence naming the specific clause that concerns you most, then the score. Then, at the end, output the JSON array of {id, risk_score} only.Reasoning first, tidy structure last. You get both, in that order.
The same applies to tight word counts on hard questions. "Explain this in exactly 50 words" spends effort on the counting. If accuracy matters more than tidiness, let it work in prose and then ask for the short version in a second turn.
A small thing that saves real time
Name the destination, not just the shape. "This is going into a slide, so no sentence longer than eight words." "This is going into an email to a client who has already complained twice." "This is going into a spreadsheet, so no commas inside fields."
The destination implies a dozen format rules you would otherwise have to write out one at a time, and it stops the output arriving in a form that technically matches your request and is still unusable.
Before you move on