Designing a Good Schema

Schema

Part of: Structured Outputs

A vague schema is a polite invitation for the model to surprise you. Ask for a status string and one call returns "shipped", the next "Shipped", the next "in transit (probably)". The model did nothing wrong: you left the door open. A good schema closes the doors you don't want opened , so the only outputs that fit are the ones your code can handle. What it is A schema is the contract that pins down the shape of structured output: which keys exist, what type each value is, which fields are required , and what values are even allowed. Designing one well is less about syntax and more about prediction: you are forecasting every way a field could go wrong and ruling those ways out in advance. The three levers you control are types (string, integer, number, boolean), enums (a fixed set of allowed values), and the required vs optional split (which keys must always appear). How it works Walk through tightening a loose field into a safe one: 1. Pick the narrowest type. A quantity is an integer, not a string "5". A price is a number. A flag is a boolean, never the string "true". 2. Use an enum for known categories. A status is not free text, it is one of ["pending", "shipped", "delivered"].

Challenge: The Schema Gate