Output Template

The pre-written text structure containing placeholders that the model must populate. This skeleton defines the overall format (e.g., JSON, XML, YAML, Markdown) and the literal characters (like brackets, commas, keys) that surround the model's generated content.

• Example: {"name": "{{NAME}}", "score": {{SCORE}}}
• The model's task is to replace {{NAME}} and {{SCORE}} with appropriate values, preserving the surrounding JSON syntax.

Markers within the skeleton that indicate where the model should insert its generated content. These are often denoted with special syntax like double curly braces {{ }}, XML tags <tag></tag>, or descriptive text in all caps.

• They act as instructional targets for the model.
• Clear, unambiguous placeholders (e.g., {{CITY}}) lead to better adherence than vague ones (e.g., {{answer}}).
• The prompt must explicitly instruct the model to replace these variables.

Explicit instructions defining the data types and rules for each placeholder. This is often provided in natural language alongside the template.

• Crucial for type enforcement: Specifies if a placeholder expects a string, integer, boolean, list, or a nested object.
• May include constraints: {{SCORE}} must be an integer between 0-100.
• Can define enumerations: {{STATUS}} must be one of: ["PENDING", "APPROVED", "REJECTED"].
• This specification bridges the template's structure with the required semantic content.

Few-shot examples showing the template correctly filled with sample data. These are the primary method for teaching the model the expected format and content relationship.

• A demonstration consists of an input query and the completed output template.
• Example:
  • Input: "Summarize the article about Paris."
  • Output Template Filled: {"summary": "{{SUMMARY}}", "city": "{{CITY}}", "word_count": {{COUNT}}} → {"summary": "An overview of Parisian culture...", "city": "Paris", "word_count": 42}
• Multiple demonstrations improve reliability and handle edge cases.

Special characters or phrases used to unambiguously separate the template from other parts of the prompt (like instructions or user input). This prevents the model from confusing the template with general instructions.

• Common delimiters include:
  • Triple backticks: template ...
  • XML tags: <template> ... </template>
  • Explicit phrases: START TEMPLATE ... END TEMPLATE
• Escape sequences may be needed if the template itself contains characters that could conflict with the delimiter (e.g., a JSON template containing backticks).

The technical layer that enforces the template's syntax during token generation. While the prompt provides the template, system-level constraints guarantee valid output.

• Grammar-Based Decoding: Uses a formal grammar (e.g., JSON grammar) to restrict the model to only generate tokens that result in syntactically valid output matching the template skeleton.
• JSON Mode: An API parameter (e.g., in OpenAI) that forces the model to output valid JSON, aligning with a JSON template.
• This component ensures the output is deterministically parsable by downstream code, even if the model makes a content error.

This template embeds a JSON Schema definition directly within the prompt, instructing the model to generate a response that validates against it. The schema defines required properties, data types, and nested structures.

• Example Prompt Snippet: Generate a product description. Output must be valid JSON matching this schema: {"type": "object", "properties": {"name": {"type": "string"}, "price": {"type": "number"}, "in_stock": {"type": "boolean"}}}
• Primary Use: Guaranteeing type-safe JSON for direct ingestion by APIs or databases.
• Key Mechanism: The model uses the schema as a blueprint for its output structure.

This template uses XML-style tags to create a clear, hierarchical skeleton for the model to fill. Tags act as unambiguous placeholders for specific data points.

• Example Prompt Snippet: Summarize the news article. Use this format: <summary><headline>TEXT</headline><date>TEXT</date><key_points><point>TEXT</point></key_points></summary>
• Primary Use: Extracting structured information from unstructured text where a formal schema is not required.
• Key Mechanism: The opening and closing tags provide explicit boundaries for each data field, reducing formatting errors.

This template provides a Markdown table header with column names, instructing the model to populate the rows. It's effective for comparative or list-based data.

• Example Prompt Snippet: Compare Python and JavaScript. Output a Markdown table: | Feature | Python | JavaScript | |---------|--------|------------|
• Primary Use: Generating consistently formatted comparative data for documentation or reports.
• Key Mechanism: The model aligns its reasoning with the columnar structure, filling each cell appropriately.

Platforms like the OpenAI API provide a response_format parameter (e.g., { "type": "json_object" }) to enforce JSON output at the system level. This is often more reliable than in-prompt instructions alone.

• How it Works: The API configures the model's decoding process to guarantee a valid JSON object is generated, often by prepending a hidden syntactic cue.
• Primary Use: Production applications requiring a strict, parseable JSON contract with the LLM.
• Key Mechanism: Inference-time constraint applied by the API, independent of the prompt's natural language instructions.

Common in content generation systems, this template asks for data to be placed within a YAML frontmatter block (delimited by ---) followed by free-text content.

• Example Prompt Snippet: `Write a blog post about Kubernetes. Start with a YAML frontmatter block:

title: author: tags: ---`

• Primary Use: Generating structured metadata and unstructured content in a single response, compatible with static site generators like Jekyll or Hugo.
• Key Mechanism: The model first populates the key-value pairs in the structured block, then proceeds to generate prose.

Within tool-calling or function-calling frameworks, the output template defines the expected arguments for a specific function. The model's role is to populate this argument structure based on the user query.

• Example Prompt Context: The system defines a tool: {"type": "function", "function": {"name": "get_weather", "parameters": {"type": "object", "properties": {"location": {"type": "string"}, "unit": {"enum": ["celsius", "fahrenheit"]}}}}}
• Primary Use: Enabling models to interact with external APIs by generating precisely formatted call arguments.
• Key Mechanism: The model's output is constrained to a valid JSON object that matches the function's parameter schema.

A constrained decoding technique that restricts a language model's token-by-token generation to follow a formal grammar (e.g., defined in EBNF), ensuring syntactically valid output in formats like JSON, SQL, or custom DSLs.

• How it Works: The decoder uses the grammar as a finite-state machine to filter the model's vocabulary at each generation step, allowing only tokens that lead to a complete, valid parse tree.
• Advantage over Simple JSON Mode: Provides finer-grained control, enabling enforcement of complex, nested structures and custom formats beyond standard JSON.

A prompt design pattern where the instruction and context are organized in a specific, often non-natural language format—such as using XML tags or YAML frontmatter—to improve the model's adherence to output formatting rules.

• Example: Wrapping different parts of the prompt in <instruction>, <context>, and <output_format> tags.
• Purpose: Creates a visual and syntactic scaffold that the model can mimic, making the boundary between the prompt and the desired output template clearer.

A formal specification, often defined using JSON Schema or a similar language, that defines the exact structure, data types, and validation rules expected from a model's output. It is the blueprint for a Data Contract with the LLM.

• Components: Defines required/optional fields, allowed value types (string, number, boolean, array, object), and potential constraints (enums, regex patterns, ranges).
• Usage: Used both as a prompt guide (via Schema Injection) and as the definitive rule set for automated Output Validation.

The reliable, rule-based extraction of data from a model's structured output, enabled by engineering guarantees that the output will match an expected, parseable format like JSON or XML.

• Prerequisite: Depends entirely on successful JSON Schema Enforcement or Grammar-Based Decoding to ensure the output is syntactically valid.
• Result: Eliminates the need for fragile, heuristic-based text scraping, allowing downstream code to treat the LLM as a reliable API that returns typed data objects.

A single, standardized representation (e.g., a specific JSON structure or XML schema) to which all model outputs for a given task are coerced. This ensures consistency across different model versions, prompts, or runs.

• Process: Often achieved through a combination of Output Templates in the prompt and Output Normalization in post-processing.
• Example: Converting various user-input date strings ("Jan 5, 2024", "05/01/24") into a canonical ISO 8601 format ("2024-01-05") within the structured output.