An output schema defines required fields, types, and allowed values for a downstream reader. It should include a representation for missing or insufficient evidence rather than forcing every case into a confident label. The application validates both structure and business rules after generation. For example, a date string can be valid JSON while referring to an event that is absent from the input. Keep generated explanations and evidence IDs separate from fields that authorize an action. If a provider supports constrained structured output, use it for syntax; keep semantic verification in application code.
Make this comfortable
Output contracts: parse a result and preserve an explicit unknown state
Decision in practice
A maintenance desk extracts warranty decisions from service notes. The result requires case_id, decision, evidence_rows, and uncertainty_reason. Decision may be approve, deny, or review. The schema forbids an empty evidence list for approve or deny, and the validator checks that each evidence row exists in the supplied case. A note that says the purchase receipt is missing must return review with a reason. The team rejects a syntactically valid approve result when its cited receipt row does not exist. A human signs off before the result changes an account balance.
{"case_id":"SR-274","decision":"review","evidence_rows":["note-7"],"uncertainty_reason":"Purchase date absent"}Performance and operating cost
Schema validation is usually linear in output size; verifying evidence references adds lookups against the input, which can be indexed. Retry only for repairable format errors and cap attempts, since repeated model calls consume money and can create new inconsistencies. Count structural failures separately from unsupported decisions. A parser rejecting a response is preferable to silently assigning a default decision. A short output also reduces review cost, provided it retains the evidence needed to audit the result.
Common Mistakes
- Do not treat valid JSON as verified truth.
- Do not force an unknown case into a binary decision.
- Do not execute a financial effect from a model field without application checks.
Connected lessons
- Prompt Engineering
- Prompt inputs: normalize records before asking for conclusions
- Prompt evaluation: test failures before rewriting the wording
- Few-shot prompting: select examples that cover decisions, not just easy cases
- Prompt decomposition: split stages at verifiable handoffs
- Project: evaluate an incident handoff prompt
- Prompt design decisions
Further prompt decisions
Test the task on changed inputs and record what the application actually accepted or rejected.
- Streaming responses: validate the complete artifact before an effect
- Human handoff: preserve evidence and the reason for uncertainty
Next decision
Check whether the right facts reached the workflow and whether the result is safe at its destination.
- Selective answers: measure when to abstain
- Generated output: validate again at the destination boundary
Continue with: Structured outputs: repair format without changing the decision.
Continue with: API prompts: document the full operation matrix.
prompt engineering
tutorial