Examples and Output Contracts
Use representative examples and explicit output contracts to make responses easier to consume and validate.
By the end
You will be able to
- Choose examples that demonstrate desired behavior without hiding the governing rule.
- Define a human-readable or machine-readable output contract.
- Distinguish requested formatting, valid JSON, and schema-constrained output.
- Validate content and edge cases after structural parsing succeeds.
Examples demonstrate a pattern
Examples can show tone, classification boundaries, field population, and how unusual inputs should be handled. They work best when the desired rule is also stated explicitly.
Choose relevant and varied examples. Repeating one easy case can teach an accidental pattern and conceal how the task should behave at its boundaries.
Define the output before generating it
An output contract names the fields or sections, allowed values, required evidence, ordering, length, and behavior when data is unknown. This makes the response easier for a person or application to inspect.
For prose, a heading template or table may be enough. For application data, use a supported structured-output or schema mechanism when the provider offers one instead of relying only on instructions to produce JSON.
Deliverable purpose: [WHO USES IT AND WHY]
Format: [PROSE, TABLE, OR NAMED SCHEMA]
Required fields/sections: [LIST]
Allowed values: [ENUMS OR RULES]
Evidence: [CITATIONS, QUOTES, TESTS, OR NONE]
Unknown values: [NULL, OMIT, OR EXPLAIN]
Ordering and limits: [RULES]
Validation: [PARSER/SCHEMA PLUS CONTENT CHECKS]Formatting, valid data, and schema adherence differ
A prompt can request a layout, but the response may still vary. JSON mode or an equivalent feature can require syntactically valid JSON without guaranteeing that every required field and type matches your contract. Schema-constrained output is designed to enforce a supported schema.
Provider capabilities and supported schema subsets vary. Keep the portable contract separate from provider-specific API configuration, and test the exact model and interface you deploy.
A valid shape can still contain a bad answer
Parsing proves structure, not factual correctness, completeness, authorization, or usefulness. Validate required business rules, source support, allowed values, cross-field consistency, and downstream consequences.
Handle refusals, incomplete output, missing data, and validation errors explicitly. Never convert a parse failure into fabricated default values that look authoritative.
Practice activity
Design and test an output contract
- Choose a recurring task such as issue triage, meeting-summary extraction, or product comparison.
- Define purpose, required fields, allowed values, evidence, unknown-value behavior, ordering, and validation.
- Create three examples: a normal case, a boundary case, and a case with missing information.
- Review a sample response twice—first for structure, then for factual and business-rule correctness.
What to produce
- A completed output contract and three varied input/output examples.
- A two-part validation checklist separating structural checks from content and consequence checks.
Reflect before continuing
What error would pass your structural validation but still make the result unsafe or useless?
Evidence
Sources and verification
- Structured model outputsOpenAI · verified 2026-07-25
- Increase output consistencyAnthropic · verified 2026-07-25
- Structured outputsGoogle · verified 2026-07-25
Knowledge check
Make it stick.
Choose the strongest answer for each question. Your attempts become part of your device-local transcript.