Output validation depends on the destination. A JSON parser checks structure, but a rendered web page also needs HTML-safe handling, a database query needs parameterization, and a tool action needs authorization. Treat generated text as untrusted data even after the model follows its prompt. Keep the model's proposed value separate from the command that uses it. Escape for the specific output context, enforce allowlists where appropriate, and reject unexpected fields before passing the result to another component.
Make this comfortable
Generated output: validate again at the destination boundary
Decision in practice
A support assistant drafts a case title that includes markup from a customer note. The output schema accepts the title as a string. The UI renders it as text, not raw HTML, so the markup cannot become a script element. A second field proposes a refund amount; the executor ignores that field until it checks the actor, invoice, balance, and effect key. The team tests both sinks with hostile strings and malformed numbers. One successful JSON parse does not cover either downstream boundary.
Model result: {title: customer_text, proposed_refund: 47.00}.
UI sink: render title as text with context-appropriate encoding.
Effect sink: validate actor, invoice, amount, idempotency key.
Reject: unexpected fields or a failed business rule.Performance and operating cost
Sink-specific checks add parsing and policy work, usually small compared with a model call. For output of size B, escaping and schema validation are generally O(B), while authorization may need a database read. The checks prevent one model error from becoming code execution, a malformed query, or an unauthorized effect. Measure rejected values by sink and review whether the prompt is producing avoidable garbage, but never remove the sink check merely because recent prompts behaved well.
Common Mistakes
- Do not render generated markup as trusted HTML.
- Do not build a database command by concatenating model text.
- Do not confuse schema validity with permission to act.
Connected lessons
- Prompt Engineering
- Production prompt engineering
- Output contracts: parse a result and preserve an explicit unknown state
- Tool calls: validate intent and arguments before an external effect
- Evaluation leakage: keep the release test independent
- Project: measure a retrieval-backed answer gate
- Prompt evidence and output decisions
Apply the boundary
Use the artifact's source and destination to decide what must be checked before the result is accepted.
Continue with: Sensitive output gates: check the rendered answer before release.
Field guide: Prompt failure diagnosis: find the broken contract first.
Continue with: Semantic output prompts: verify structure after generation.
Continue with: UI code prompts: reuse tokens and components with a change gate.
Continue with: PDF export prompts: verify the delivered file again.
prompt engineering
tutorial