How to structure prompts for reliable JSON output, in 2026
Structured output APIs killed most JSON parsing pain, but schema design still decides quality. Field names, descriptions and enum choices are the new prompt engineering. Demo content.
Native structured output support across all major APIs has eliminated JSON parsing failures, but output quality still varies enormously with schema design. The schema is now part of the prompt.
Principles that hold up
- ▸Field names are instructions:
severity_reasoningyields better analysis thannotes - ▸Order fields so reasoning comes before conclusions — models fill schemas top to bottom
- ▸Enums beat free strings anywhere values are bounded
- ▸Description fields in JSON Schema are read as carefully as system prompt text
A pattern that works
{
"type": "object",
"properties": {
"evidence": { "type": "string", "description": "Quote the exact lines that support the finding" },
"reasoning": { "type": "string" },
"verdict": { "type": "string", "enum": ["confirmed", "plausible", "refuted"] }
},
"required": ["evidence", "reasoning", "verdict"]
}Putting evidence first forces grounding before judgment, measurably reducing hallucinated verdicts.
Teams treating schemas as versioned, evaluated prompt assets consistently outperform those treating them as data plumbing.