Response Schema

The formal language used to author the schema itself. JSON Schema is the predominant standard, providing a vocabulary to define objects, properties, data types, and validation rules. Alternatives include OpenAPI schemas for API responses, Protocol Buffers (.proto files), or XML Schema (XSD). The choice dictates the tooling for validation and generation.

Defines the top-level container and the hierarchical nesting of the output. This specifies whether the response is a single object, an array of items, or a primitive value. It enforces the data shape, dictating the exact relationship between parent and child elements, which is critical for deterministic parsing by consuming applications.

• Example: A root object containing an items array, where each item has id, name, and metadata fields.

The core specification for each field within the structure. For every property, the schema defines:

• Data Type: string, number, integer, boolean, array, object, or null.
• Constraints: For strings: minLength, maxLength, pattern (regex). For numbers: minimum, maximum.
• Required/Optional: A list of properties that must be present for the object to be valid.

This provides type enforcement, ensuring numerical values aren't output as strings and that strings match expected patterns like dates or IDs.

Rules that enforce logical consistency and business logic beyond basic syntax. These are the semantic guarantees of the data contract. Key rules include:

• enum: Restricts a value to a predefined list of allowed strings.
• const: Requires an exact, fixed value.
• oneOf/anyOf: Defines union types or conditional structures.
• if/then/else: Creates conditional property requirements.
• patternProperties: Applies rules to property names matching a regex.

These rules move beyond syntactic validity to ensure semantic validity for the use case.

Human-readable annotations embedded within the schema to guide both model generation and developer consumption. This includes:

• title and description: Explain the purpose of the schema or a specific property. These are often used in format-aware prompting.
• examples: Provides sample valid values for a property or the entire object, serving as few-shot examples for the model.
• $comment: Technical notes for schema maintainers.

This metadata bridges the formal specification and the natural language context understood by the LLM.

The technical method used to guarantee the model's output adheres to the schema. This is not part of the schema document itself but is the critical runtime component. Mechanisms include:

• Grammar-Based Decoding: Uses the schema to generate a formal grammar (e.g., JSON Grammar) for constrained decoding.
• JSON Mode: A model/API parameter that forces valid JSON output.
• Post-Generation Validation: Parsing the output and validating it against the schema with a library like jsonschema.
• Schema-Aware Decoding: An advanced inference-time algorithm that dynamically guides token selection.

The mechanism provides the data format guarantee.

A purely in-context method where the prompt includes an explicit output template or format specification. This involves:

• Providing a JSON Schema in the system prompt.
• Using XML or other delimiters to structure the instruction.
• Including a filled example (few-shot learning) that demonstrates the exact output structure.
• Leaving placeholders (e.g., {"name": "", "value": ""}) for the model to complete. This technique relies on the model's instruction-following capability and is the most portable across different model providers, but offers no hard guarantee of valid syntax.

An advanced form of constrained decoding where the generation process is dynamically guided by a live representation of the output schema. Unlike a static grammar, this method can be semantically aware, ensuring generated values match expected data types (string, number, boolean) and adhere to constraints like enums or patterns. Some implementations work by constructing a finite-state machine from the JSON Schema during decoding, validating the structure and content in real-time. This provides the strongest guarantee, combining syntactic and basic semantic validation.

This method accepts the model's raw text output and applies deterministic parsing and validation as a separate step. It involves:

• Attempting to parse the output with a standard library (e.g., json.loads() in Python).
• Validating the parsed object against a formal schema using a library like jsonschema.
• Implementing fallback logic (e.g., regex extraction, retry with a corrected prompt) if parsing fails. While this doesn't prevent invalid generation, it is essential for production robustness, providing a clear pass/fail gate before data flows to downstream systems.

A Constrained Decoding technique that restricts a model's token-by-token generation to follow a formal grammar, ensuring syntactically valid output. Instead of sampling from the full vocabulary, the decoder is guided by a state machine derived from a grammar definition (e.g., in EBNF). Key applications include:

• Guaranteeing valid JSON, XML, or SQL syntax.
• Enforcing an Output Grammar for custom formats.
• Preventing parsing failures by avoiding malformed brackets or missing commas.
• Enabling Schema-Aware Decoding where the grammar is dynamically generated from a schema.

The task of using a language model to identify and pull specific entities, relationships, or facts from unstructured text and output them in a predefined Structured LLM Output format. This transforms prose into queryable data. The process typically involves:

• Schema-Guided Generation where the target schema defines the fields to extract.
• Output Templates with placeholders for the model to fill.
• Canonical Format normalization (e.g., all dates to ISO 8601).
• Output Post-Processing for validation and cleaning. Common use cases include pulling contact info from emails, extracting line items from invoices, or summarizing research papers into structured records.

The automated processes applied to a model's raw response to ensure safety, correctness, and usability before downstream consumption.

• Output Validation: Checks the response against a Response Schema or set of business rules. This verifies Data Shape Enforcement, required fields, and data type correctness. Tools like Pydantic or JSON Schema validators are commonly used.
• Output Sanitization: Removes or escapes potentially dangerous content, such as:
  • Malformed JSON that could break parsers.
  • HTML/JavaScript injection code.
  • Prompt leakage or system instructions.
  • Control characters. This step is critical for security in API Response Format pipelines.

A Canonical Format is a single, standardized representation to which all model outputs for a given task are coerced, ensuring consistency for downstream systems.

• Canonical JSON: A strict JSON format with rules for key ordering, number representation, and whitespace to enable byte-for-byte comparison and hashing.
• Output Normalization: The post-processing step that transforms a model's raw text into this canonical form. Examples include:
  • Converting "$1,234.56" and "1.234k" to the float 1234.56.
  • Mapping "true", "yes", "1" to the boolean true.
  • Standardizing country names to ISO 3166-1 alpha-2 codes. This guarantees a Data Format Guarantee for integrating systems.