Tool use with a JSON schema is the most reliable route to guaranteed schema-compliant output — define an extraction tool whose input schema matches your target structure, then read the extracted data straight from the tool_use response. This eliminates JSON syntax errors entirely.
The caveat that will show up on the exam, stated as plainly as possible: strict schemas eliminate syntax errors, never semantic errors. Line items that don't sum to the stated total, values placed in the wrong field, plausible-but-wrong dates — all of these pass schema validation cleanly, because the schema only constrains shape, never meaning.
Schema design principles, in rough order of exam-relevance:
- Make fields optional/nullable whenever the source may genuinely lack the information. A required field pressures the model to fabricate a plausible-looking value just to satisfy the schema — this is the single highest-yield schema principle tested on the exam.
- Add
"unclear"as an enum value for genuinely ambiguous cases, rather than forcing a forced-choice guess between the defined categories. - Use
"other"plus a free-text detail string for extensible categorization, so a genuinely novel category degrades gracefully into something a human can still read, instead of getting silently miscategorized into the nearest defined option. - Put format-normalization rules in the prompt, alongside the strict schema — the schema constrains shape; the prompt is where you handle messy, inconsistent source formatting before it hits that shape.
tool_choice in this context: "auto" is insufficient whenever a call must be guaranteed (the model may simply return prose instead); "any" guarantees some call happens when multiple possible schemas exist and the document type isn't known in advance; forcing a specific named tool guarantees a particular extraction step runs first.
Schema Design Rules — quick reference
- Make fields nullable when the source data may genuinely be absent.
- Add an
"unclear"enum value for genuine ambiguity.- Add
"other"+ a detail string for graceful handling of novelty.- Schemas enforce shape, never meaning — don't reach for a schema change to fix a semantic problem.
- Use
tool_choice: "any"when the right schema depends on input that isn't known in advance.
The discriminator: shape versus meaning. If the actual complaint is about values being wrong rather than output being malformed, no schema change — tighter types, added constraints, stricter enums — fixes it. That's a semantic problem, and semantic problems need semantic solutions (§4).