Prompt pattern library
Structured output patterns
When another person or system must consume the result, specify fields, allowed values, and empty-value rules—then validate outside the chat.
Before you start
Why this matters
A paragraph summary can be perfect for a human reader and useless for a spreadsheet, ticket system, or automated check. Structured output patterns ask for labeled fields, tables, or JSON-like shapes so the result can be sorted, filtered, tested, or handed to software.
Structure does not make content true. A neat JSON object can still contain invented dates. The pattern improves parsability and reviewability when paired with evidence rules and validation.
1Learn the idea
Read
When to use structure
Choose structured output when you need:
- consistent fields across many items;
- machine parsing or copy into another tool;
- explicit nulls instead of omitted facts;
- side-by-side comparison across cases;
- evaluation against an expected schema.
Stay with prose when the goal is persuasion, storytelling, tutoring dialogue, or open brainstorming. Forcing JSON onto every task adds friction without benefit.
Read
Define the schema in plain language
You do not need formal JSON Schema to start. Specify:
- field names;
- types or allowed values;
- required versus optional fields;
- what to do when unknown;
- whether extra fields are forbidden.
Example:
Return only these fields:
- decision: string or "NONE"
- owner: string or "TBD"
- due_date: YYYY-MM-DD or null
- evidence: short quote from the notes
- confidence: high | medium | low
Rules:
- Use null or TBD rather than guessing.
- evidence must be copied from the notes.
- If no decision exists, decision="NONE".
The empty-value rule is as important as the field list. Without it, models fill gaps with confident fiction to keep the shape pretty.
Read
Ask for evidence fields
For extraction and classification, include a field that points back to source text: quote, line reference, or “not in source.” This makes review faster and discourages unsupported claims. For recommendations, separate recommendation from assumptions and open_questions.
Read
Validate outside the model
Treat model output as untrusted input. Check that required keys exist, enums match, dates parse, and unknown values follow the empty rule. In product settings, use schema validation and retries. In personal workflows, skim the fields before you paste them into a live system.
Structured mode features in some tools reduce formatting errors; they do not verify factual grounding. Keep a human or automated check for consequential fields.
Teach
Combine with few-shot and role patterns
Show one or two example objects when the schema is subtle. Keep examples consistent with the empty-value policy. Use a role only if it changes review behavior, such as “skeptical extractor.” Do not let a creative role override the schema.
Read
Common failure modes
- Pretty invalid JSON with trailing commentary.
- Valid shape, invented values.
- Collapsed fields that mix evidence and opinion.
- Schema drift when you update instructions but not examples.
- Oversized schemas that the model partially ignores—prefer the smallest schema that unblocks the next step.
Read
Keep humans in the parse loop
Even when fields look clean, treat consequential values as provisional until checked. A due date that parses is not the same as a due date that was agreed. A confidence label is a model opinion, not a measurement. Route high-impact fields through the same verification habits you would use for prose: open the source, compare numbers, and refuse to paste unchecked objects into billing, legal, or account systems.
If you build a personal workflow, add a two-minute review script: required keys present, null policy followed, evidence quotes real, enums legal, and no commentary outside the schema. That small ritual catches most structured-output failures before they spread.
Checking tutor…