Summary

Structured Output prompting ensures LLM responses conform to predefined schemas or formats. By specifying output structures (JSON, XML, specific formats), outputs become machine-readable and directly usable in downstream systems. This technique reduces parsing errors and enables reliable integration with APIs and databases.

Common formats

  • JSON: API responses, data structures
  • Markdown: Documentation, formatted text
  • Tables: Tabular data presentation
  • Code blocks: Programming language output

Implementation approaches

  1. Explicit instruction: Describe format in natural language
  2. Schema specification: Provide JSON schema or type definition
  3. Few-shot examples: Show desired output format
  4. Constrained decoding: Use API-level format controls

Validation checklist

  • Schema matches actual output
  • Required fields are present
  • Type constraints are respected
  • Edge cases are handled
  • Error recovery is planned

Build This Pattern

Copy this prompt and paste it into Claude Code, OpenCode, Codex, or Cursor to implement this pattern.

Build me a structured output system for LLMs. Architecture: define schemas using Zod for runtime validation and TypeScript type inference. Implement a schema-to-prompt converter that generates natural language descriptions of the expected output format from the Zod schema. Support multiple output modes: native structured output via response_format parameter where available, and JSON mode with post-generation validation as fallback. Include a validation pipeline that parses LLM output against the schema and provides friendly error messages pointing to specific schema violations. Error handling: if validation fails, retry with the error context injected into the prompt so the LLM can fix its output (max 2 retries). If the LLM repeatedly outputs invalid JSON, try structured output parameter first, then fall back to explicit JSON instruction. Edge cases: handle nested objects up to configurable depth. Support arrays with min-max length constraints, enums with descriptions, optional fields with defaults, and discriminated unions. Handle very large outputs by streaming validation. Best practices: include a schema definition UI for non-technical users. Log validation failures with schema path and error details. Use Zod for both server-side validation and TypeScript types. Testing: test schema-to-prompt conversion for each Zod type. Test validation with valid, invalid, and edge case outputs. Verify retry logic improves success rate. TypeScript with Zod.