Stage 3 — Output Structure Control (Critical in Production)

If the model writes “nice text” but without strict structure, integrations break.

Stage topics

• Explicit formats (JSON, tables, lists)
• Response schemas
• Output validation
• “Nothing except JSON” rule

Why structure matters more than style

In system workflows, model output is input for another service.
You need not “creative text”, but a machine-readable contract.

Explicit formats

Define:

• field types,
• required keys,
• allowed values,
• behavior on missing data.

Response schemas

Practical approach:

• describe JSON schema (or strict pseudo-schema),
• forbid extra fields,
• require valid JSON without prose wrappers.

Validation

Never trust raw model output.
Pipeline must validate:

• syntax,
• structure,
• business constraints.

“Nothing except JSON”

For integration tasks, define strict response rule:

• JSON only,
• no markdown,
• no comments,
• no extra explanatory text.

Contract-first prompting

A structured prompt should start from the consumer of the output. If a human reads the result, headings and concise paragraphs may be enough. If another service reads the result, the prompt must define a contract before generation starts. The contract should say which fields exist, what each field means, which values are allowed, and what the model must do when it cannot infer a value safely.

This is why schemas are stronger than examples alone. Examples show the shape, but schemas define the rule. In production, the safest workflow is prompt -> model output -> parser -> validator -> business decision. The model should never be the only component deciding that its own output is valid.

Core theory to retain

• Model behavior must be constrained by explicit boundaries.
• Free-form text is an anti-pattern for automated integrations.

Beginner explanation

A prompt template is useful when the same task will run many times: different users, different documents, different input data, but the same expected result. Without a template, every developer writes the request differently, and outputs start varying in structure, style, and completeness. In a product, this quickly becomes a problem because downstream code cannot reliably parse free-form prose.

The simplest template has a stable part and variables. The stable part describes the task, rules, and format. Variables are filled at runtime: support message, user language, allowed categories, or documentation excerpt. This prompt can be stored, reviewed, and tested as an artifact.

Classify the user support message.
Allowed categories: {{categories}}.
Message: {{message}}.

Return JSON:
{
  "category": "one_of_categories",
  "confidence": 0.0,
  "reason": "short explanation"
}

If the model must return JSON, the word “JSON” is not enough. Show fields, types, and constraints. Then the application must validate the response with a schema validator. The prompt asks the model to follow the contract, while the backend checks that the contract was actually followed. This matters when output goes into a database, API, queue, or automated action.

Mini scenarios from real projects

• Integration fails at parsing: model adds explanatory text around JSON.
• Output is syntactically valid but fails business checks: schema does not encode required constraints.
• Different endpoints return different structures for the same task: no unified output contract.

Fast decision rules

• For integrations, always define strict output format and field requirements.
• Validation should be two-layered: syntax (schema) and business rules.
• Use free-form text only where product value explicitly requires it.

Self-check questions

1. Why does “valid JSON” not automatically mean “production-ready”?
2. Which constraints should be encoded directly in response schema?
3. When is free-form output justified instead of structured output?