In brief
- Use the smallest schema the workflow needs.
- Validate before side effects.
- Bound and measure repair attempts.
Treat the schema as application code
Define required fields, enums, size limits, and whether unknown fields are allowed. Version material changes and keep the schema near the consumer that depends on it.
Make the task and schema agree
Prompts should explain the semantic meaning of fields, not only paste a large schema. Remove fields that the model cannot infer from the provided context.
Validate before acting
Parse, validate, apply business rules, and only then write to a database or invoke a tool. Keep raw invalid output available under a safe debugging policy.
- Syntax parse
- Schema validation
- Cross-field business rules
- Permission and safety checks
- Side effect
Repair narrowly and stop
A repair pass can receive the validation errors and original output, but it needs a small attempt limit and the same deadline. Record repair rate by model and schema because frequent repair is a quality signal.
Never coerce an ambiguous high-impact field merely to make validation pass.
Frequently asked
Questions, answered plainly.
Is valid JSON enough for structured output?+
No. JSON syntax can be valid while required fields, types, enums, or business rules are wrong.
Should invalid output be automatically repaired?+
For low-risk workflows, a bounded repair pass can help. High-impact ambiguity should fail for explicit handling rather than being guessed.
What should be monitored?+
Track first-pass validity, repair success, semantic rejection, latency, and failure by model and schema version.
Sources and next paths