An answer can look like JSON and still be unusable for the job waiting after it. A missing field, an unexpected status or a number stored as text can interrupt an import. Defining the structure first gives you a way to check the output mechanically, while keeping a separate review for whether the values are true.
Start with the receiving task Suppose you want to extract actions from fictional meeting notes into a small project tracker. Each action needs an identifier, a description, a status and an owner. Some actions have no agreed deadline. Decide how the tracker should represent that absence before asking an assistant to produce records.
Write a tiny example by hand. Use two actions, including one with no owner and no deadline. If the example is awkward to import, fix the structure now. Generating fifty records will only multiply the same problem.
Decide what each field means A field called “date” is ambiguous. It could mean the meeting date, the deadline or the date the record was created. Use a name that describes the purpose, such as “due_date,” and document the expected format. Keep time-zone information where the receiving workflow needs an exact moment rather than a calendar day.
Choose required fields deliberately. An identifier may be required for every record, while an owner can be absent if the meeting did not assign one. Do not turn missing information into an empty promise, a zero value or a guessed name simply to fill a box.
Constrain values that drive behaviour If your tracker recognises only “open,” “in_progress” and “done,” define those allowed values. A model may otherwise choose “pending,” “started” or a sentence explaining the status. Those phrases may be understandable to a person but incompatible with the next system.
Set bounds where they matter. A quantity cannot be negative in some workflows; a confidence field might permit only a particular range. Explain the rule in the task brief as well as the structure so the assistant has a chance to produce the intended values.
Test an invalid example Deliberately change one status to “nearly finished,” remove an identifier and add an unexpected field. Your validator should point to the affected location rather than simply say that something is wrong. For a list of records, a path identifying the item and field makes repair much easier.
Give the assistant those exact errors when requesting a correction. Keep the original source and ask it to preserve already valid facts. After the repair, validate again; do not assume a response described as corrected actually meets the contract.
Review meaning after structure A structurally valid record can still assign an action to the wrong person. Compare each extracted action with the meeting notes. Distinguish a proposal from an agreed task, and leave an unassigned owner unassigned. Structural checks and source checks answer different questions.
Save the schema, a valid example, a few invalid cases and the extraction prompt together. This small bundle makes future changes easier to review. When the tracker adds a new field, update the examples and checks before running another batch. The most useful output is not merely well formatted; it can enter the intended workflow without concealing uncertainty.
Keep the inputs and review notes together in the structured output studio workspace, then save a backup you can reopen.