Reliable structured output starts before the model generates its first token. This guide provides reusable prompt templates for JSON, SQL, and CSV, plus a practical workflow for defining schemas, adding examples, validating responses, and deciding when a failed output should be repaired or rejected.
Overview
LLMs generate text, even when the requested result looks like data. A prompt that says “return JSON” may still produce markdown fences, explanatory prose, missing fields, invalid escapes, or values with the wrong types. Structured-output prompts reduce these problems by making the contract explicit, separating instructions from input data, and pairing generation with automated validation.
The most dependable pattern is:
- Define the output contract, including required fields, types, allowed values, and null handling.
- Write a system instruction that describes the role, format, and failure behaviour.
- Place the user’s data in a clearly marked section.
- Add a small few-shot example when the format or transformation is ambiguous.
- Validate the response outside the model before using it.
- Repair, retry, or reject invalid output according to a documented policy.
Prompt wording is only one part of reliability. Where an API offers native structured output, schema-constrained generation, or tool calling, consider using it alongside prompt instructions. Treat provider-specific features as implementation details to retest when changing models or API versions.
Checklist by scenario
JSON extraction and transformation
Use JSON when another program needs named fields, nested objects, or arrays. Define the shape before writing the prompt. For example, decide whether an absent value is represented by null, an empty string, or an omitted property.
SYSTEM
You extract information from the supplied document.
Return exactly one valid JSON object. Do not use Markdown fences,
comments, or explanatory text.
Required schema:
{
"title": string,
"category": string,
"priority": "low" | "medium" | "high",
"tags": string[],
"due_date": string | null
}
Rules:
- Use only information present in the document.
- Use null when a value is not stated.
- Do not guess dates, categories, or priorities.
- Escape quotation marks and line breaks so the result is valid JSON.
USER
<document>
{{DOCUMENT_TEXT}}
</document>Before production use, replace the informal schema notation with a machine-readable JSON Schema or equivalent validator. If the input contains instructions, treat it as data rather than as a new system instruction. This is particularly important when processing web pages, support tickets, or documents supplied by other users. For a broader defensive workflow, see the prompt injection testing guide.
SQL query generation
SQL generation needs more than a request such as “find recent orders.” Supply the SQL dialect, schema, relationships, permitted operations, and expected parameters. Prefer parameter placeholders over interpolated user values.
SYSTEM
You write read-only {{SQL_DIALECT}} queries for the database schema below.
Return only one SQL statement. Do not return Markdown, comments,
multiple statements, or explanatory text.
Allowed operation: SELECT only.
Schema:
{{SCHEMA_DEFINITION}}
Rules:
- Use only tables and columns listed in the schema.
- Use named parameters such as :start_date rather than embedding values.
- Include an explicit LIMIT of {{MAX_ROWS}} unless the request requires aggregation.
- If the request is ambiguous or cannot be answered from the schema, return:
{"error":"cannot_generate_query","reason":"brief reason"}
USER
Request: {{NATURAL_LANGUAGE_REQUEST}}For a safer application, do not execute generated SQL merely because it parses. Validate the statement type, referenced tables, selected columns, parameter names, and row limit. Run it with a database identity that has only the required read permissions, and consider a parser or query policy layer. SQL formatting and testing utilities can help during development, but formatting does not prove that a query is safe or semantically correct.
CSV or tabular export
CSV is simple to read and surprisingly easy to break. Specify the exact column order, one-record-per-row rule, delimiter, quote character, line-ending expectations, and treatment of commas, quotes, and newlines inside values.
SYSTEM
Convert the supplied records into CSV.
Return only the CSV body; do not include a title, Markdown fence, or explanation.
Requirements:
- Header row and data rows must use this exact column order:
id,name,description,status
- Use a comma delimiter and double quotes where needed.
- Escape an internal double quote by doubling it.
- Keep line breaks inside a field quoted; do not create an extra record.
- Use an empty field for an unknown value.
- Create exactly one row per input record.
USER
<records>
{{RECORDS}}
</records>For higher reliability, ask the model for an array of typed records first, validate that array, and perform CSV serialization in application code. This separates interpretation from formatting and avoids relying on the model to implement every CSV edge case.
What to double-check
Schema and types
- Are required and optional fields clearly distinguished?
- Are numbers, booleans, dates, identifiers, and currency values represented consistently?
- Are enumerated values listed exactly, including case?
- Is the policy for unknown, empty, and null values explicit?
- Are extra properties rejected, ignored, or preserved?
Prompt boundaries and examples
Put untrusted or variable content between unmistakable delimiters such as <document> tags. Tell the model that the content is data to transform, not instructions to follow. Use few-shot prompting when a representative example clarifies a difficult distinction, such as whether a date is inferred or copied. Keep examples small and ensure they obey the same schema as real output. A contradictory example can make a carefully written prompt less reliable.
Generation settings and transport
Choose conservative generation settings for deterministic extraction, but do not assume that a low temperature alone guarantees valid output. Set a maximum output length that leaves room for the largest legitimate response. If streaming is enabled, collect the complete response before parsing unless your parser is designed for incremental chunks. Check how the provider handles truncation, stop sequences, Unicode, and escaped characters.
Validation and recovery
Validation should happen in code, not by visual inspection. A useful pipeline is:
- Check that the response is present and within an expected size range.
- Remove nothing silently; parse the raw response and record the exact failure.
- Validate syntax, such as JSON parsing or CSV column counts.
- Validate the schema, types, allowed values, and required fields.
- Apply domain checks, such as date ranges, identifier formats, or permitted SQL operations.
- Retry with a focused correction prompt only when the failure is recoverable.
- Send unresolved cases to a safe fallback or review queue.
Keep the original input, model identifier, prompt version, raw response, validation result, and retry count in appropriate test or audit records. Avoid logging secrets or unnecessary personal data.
Common mistakes
- Requesting valid JSON without showing the shape: “Return JSON” does not define required keys, types, or nesting.
- Mixing prose with machine output: An introductory sentence can make an otherwise valid object fail a parser. State that the response must contain only the requested format.
- Using an example that is not representative: Few-shot examples should cover realistic edge cases, not just the easiest input.
- Trusting syntax as correctness: Parseable JSON can still contain invented values; valid SQL can still answer the wrong question.
- Letting the model serialize everything: Application code is usually better suited to final CSV quoting, date normalization, and numeric formatting.
- Interpolating values into SQL: Use parameters and policy checks rather than treating generated text as trusted code.
- Repairing blindly: A second model call can hide a recurring prompt or data-quality problem. Record failures and measure repair success.
- Ignoring truncation: An incomplete final object or row should be rejected or retried, not quietly accepted.
For a repeatable quality process, combine format tests with semantic tests. The LLM evaluation guide covers ways to test prompt quality and reliability, while prompt chaining patterns can help when extraction, verification, and serialization are better handled as separate steps.
When to revisit
Revisit a structured-output prompt before deploying it to a new workflow, changing its input sources, switching LLM providers, or changing model versions. Also review it when the database schema, CSV consumer, validation library, or API response format changes. A quarterly review is a practical minimum for an actively used integration, with additional checks after major model or API changes.
Keep a small regression set containing ordinary inputs, missing fields, long text, quotes, commas, embedded line breaks, unusual Unicode, ambiguous requests, and malicious instruction-like content. Run it in CI when the prompt, model, schema, or parser changes. Compare not only whether output parses, but whether it meets field-level and task-level expectations.
Before release, use this final checklist:
- Copy the relevant template and replace every placeholder.
- Write the schema and failure policy beside the prompt.
- Add representative few-shot examples only where they resolve ambiguity.
- Test raw output, parsing, schema validation, and domain rules independently.
- Test truncated, empty, oversized, and adversarial inputs.
- Confirm SQL permissions and parameter handling, or serialize CSV in code.
- Record prompt and model versions so failures can be reproduced.
- Schedule a review when workflows, tools, or seasonal data inputs change.
Structured-output prompt engineering works best as a contract between the model and your application. Clear instructions improve the contract, but validation, safe execution, and regression testing are what make it dependable over time.
