Consistent JSON Without A Schema Library

Structured output modes are the right answer when you have one. This is what to do when you do not - an older endpoint, a local model, a provider that does not offer it.

Four rules, in order of how much they bought me.

1. Show the shape, do not describe it. One filled-in example beats a paragraph of field descriptions. The example teaches key order, nesting and types in one go, and it is impossible to misread.

2. Name the null case explicitly. This was the big one. Half my parse failures were the model deciding that a missing value warranted prose - "discount": "not specified in the input" - instead of null. So: "If a value is absent, use null. Never use a string to explain an absence."

3. Forbid the fence and the preamble in the same sentence. "Return only the JSON object. No markdown fences, no explanation before or after." Split these into two rules and you get one of them obeyed.

4. Put the schema last. Whatever sits closest to the end of the prompt gets weighted most. The document goes first, the format goes last.

`
Extract the invoice fields. Return only a JSON object matching this
example exactly - same keys, same order, same types. No markdown
fences, no explanation before or after.

If a value is absent, use null. Never use a string to explain an
absence.

{
"invoice_number": "INV-2041",
"issued_on": "2026-03-14",
"currency": "GBP",
"total": 1284.50,
"line_items": [
{ "description": "Design retainer", "quantity": 1, "unit_price": 1284.50 }
],
"purchase_order": null
}
`

Still keep the retry. This got me to a failure rate I stopped tracking, not to zero. One re-ask with the parser error appended catches essentially all of the remainder. Do not build a parser that assumes success just because the prompt got good.