PRODUCTION SCENARIO
A claims intake service uses structured outputs to return policy_number, incident_date and category. category is a string enum of fourteen claim codes, and the downstream API matches the code exactly and rejects anything else. About 2 percent of submissions come back rejected for a category that differs from a listed code only in the capitalization of one word. Every response finishes with stop_reason end_turn, never refusal and never max_tokens, and every incident_date falls inside the policy period.
Which post-parse step addresses those rejections?
Answering here is anonymous. Nothing is saved unless you sign in.
Show answer and explanation
Answer: Match the category to the enum case-insensitively, then map the canonical code
Constrained decoding does not pin the capitalization of enum and const values: Claude can return a value that differs from the schema only in a capital letter, with no error and no special stop_reason, which is exactly the 2 percent this service loses. Watching stop_reason for a refusal is the guard that matters when Claude declines a request, because the output then ignores the schema and still returns 200. Retrying at a higher ceiling is the fix when a record comes back cut off. Range-checking the date in code is needed when the risk is a value that parses but makes no sense, since numeric and length bounds sit outside the supported grammar.