Fixing the shape of the answer

Prose is not an answer you can use

Ask for the key details of 40 invoices and you will get 40 paragraphs. Each is readable. Together they are useless, because you cannot sort them, total them, paste them into a system, or notice that number 23 is missing a date.

The fix is to specify the shape of the output as precisely as you specify its content. This is one of the few pieces of prompting technique that reliably pays for itself in ordinary office work, and it takes one extra sentence.

Show the shape, do not describe it

Described: "return the supplier, the invoice number, the date and the net amount". You will get four fields in an order the model chose, with labels it chose, formatted differently on row 19 because the supplier name contained a comma.

Shown:

supplier<TAB>invoice_no<TAB>date_iso<TAB>net_amount
Acme Supplies<TAB>INV-2291<TAB>2026-03-14<TAB>1842.50

One line per invoice, in exactly this format, tab-separated, no header, no commentary before or after. Dates as YYYY-MM-DD. Amounts as digits and a decimal point only, no currency symbol, no thousands separator.

The second version pastes into a spreadsheet. The first does not, and the difference is a single demonstrated line.

Pick your separator with the data in mind. Commas break the moment a supplier is called "Smith, Jones & Co". Pipe characters break on anything containing a pipe. Tabs survive most business text. If the output is going into software rather than a spreadsheet, ask for JSON — one object per line — and let the software parse it.

The one rule that stops invention

Add this, always:

If a field is not present in the source, write NOT FOUND. Do not infer it, do not calculate it, do not use a typical value.

Without it, every field gets filled. That is not the model being dishonest; it is the mechanism. A row with a blank in the middle is an unlikely continuation of a table where every other row is complete, so the likely continuation is a plausible value. You asked for a well-formed table and a well-formed table is what you got.

With the rule, absence becomes visible — and absence is usually the thing you most needed to see. Nine invoices with NOT FOUND in the date column is a real finding about your filing. Nine invented dates is a landmine.

Put the reasoning field before the verdict field

Fields are generated in the order you list them, left to right, and each one is conditioned on the ones already written. So the order of your columns changes the answer.

Ask for verdict, reason and the model commits to a verdict and then writes a justification for a decision already made. Ask for evidence, reason, verdict and the verdict is produced after — and conditioned on — the evidence it just wrote.

This costs nothing and is worth doing on every judgement task:

quoted_evidence<TAB>reason<TAB>decision

You can discard the first two columns afterwards. They did their work during generation.

Count the rows

The most common failure of batch extraction is not a wrong value. It is a missing row, and a fixed shape is what makes it findable.

Forty invoices in, thirty-eight lines out. Nobody notices, because thirty-eight well-formed lines look exactly as convincing as forty. So:

End with a final line: COUNT=n, where n is the number of data rows you produced.

Then compare n with what you sent. When they disagree, split the batch and rerun the halves. This one habit catches more real errors in office AI work than any amount of prompt refinement.

Guaranteed shapes, if you need them

Most providers now offer a structured-output or JSON mode where you supply a schema and the shape is enforced during generation rather than requested politely. If your work feeds a system that breaks on malformed input, use it: it removes an entire class of failure.

The free path is real here too. llama.cpp and Ollama support grammar-constrained generation — you give a grammar and the model is prevented from producing anything that does not match it. A local seven-billion-parameter model with an enforced grammar is often more reliable for structured extraction than a much larger model asked nicely, because the constraint is mechanical rather than statistical.

The limitation worth knowing

Tight structure can slightly reduce quality on tasks that genuinely need room — nuanced judgement, a delicate summary. If you find the answers getting thin, keep the structure and add a free-text field at the end for anything the schema could not hold. Read that field. It is often where the model has put the thing you should have asked about.

And structure does not make a value true. A beautifully formatted table of forty net amounts is forty unverified numbers. It is easier to check than forty paragraphs, which is the entire point — but easier to check is not checked.