From a JSON reply to a reliable workflow
Specify fields, validate structure and facts, and handle incomplete output before automation.
On this page
Start with the receiving system
Before asking a model for JSON, decide what the next system needs. Choose field names, types, required fields and a representation for missing information. A predictable object is useful only if its meaning fits the task. Keep a small versioned schema with the consuming application.
Request an explicit shape
Select JSON in the playground and describe the expected fields. For example, request a summary string, a next_steps array of strings and a missing_information array. State that the result must use the supplied source rather than external guesses. The following object is illustrative, not a generated model result.
{
"summary": "The launch date has not been supplied.",
"next_steps": ["Confirm the owner and launch date."],
"missing_information": ["owner", "launch_date"]
}
Validate syntax, structure and evidence
First parse the JSON. Then reject unexpected types, omitted required fields or strings beyond your business limits. Finally check factual fields against the source. A schema validates an object’s form; it cannot establish that a date or owner is true. Preserve source identifiers if the next step needs traceability.
| Failure | Recovery |
|---|---|
| Invalid JSON | Retry once with the parser error and original task |
| Missing field | Request the required shape or return a validation error |
| Unsupported fact | Mark unknown; request source evidence |
| Truncated output | Increase the budget or reduce the extraction scope |
Treat incomplete output as incomplete
A stopped response may end in the middle of a string or object. Do not execute it or silently repair it into a confident result. In a provider integration, inspect completion status and retain the error. Reasoning can consume output tokens, so budget for it when using high effort. The API guide explains response handling.
Put a boundary before side effects
A parsed object should not automatically send an email, change an order or run a command. Validate permissions and the business action independently. Use an approval step where your application requires one. Test negative cases—wrong types, unknown identifiers, extra fields and interrupted streams—before enabling automation. Read the tool-calling section for the application’s responsibility.