Structured Output
Pedal Point wants every incoming email sorted automatically: which category, which order, how urgent. The first attempt asked the model to "summarise the email", and the replies came back as friendly paragraphs. A person can read a paragraph. Code cannot route one. When software is the reader, you need structured output.
The rule
If code will read it, ask for a schema, then validate.
Tell the model the exact shape you want, usually JSON, with named fields and allowed values:
{
"category": "order_status | returns | product_question | other",
"order_id": "string of digits, or null",
"urgency": "low | normal | high"
}(In this description the | means "one of", not literal text.)
Then the email "My order 4417 still hasn't arrived and it's a birthday gift for Saturday!" becomes:
{"category": "order_status", "order_id": "4417", "urgency": "high"}Three design habits make this reliable:
- Fixed values where code branches. Categories and urgency come from short lists, so your routing code always matches.
- Allow "nothing".
order_idmay benull. If every field is required, the model may invent a value to fill it. - Validate every time. Parse the JSON and check each field against the rules before using it.
Name fields plainly and describe each one in a sentence. The model reads names and descriptions as instructions, so urgency with the note "high only when a deadline or safety issue is mentioned" gives far more consistent labels than a bare field name.
Many model APIs can now enforce a JSON schema or a JSON-only mode, which makes invalid output far rarer. Validate anyway: correct shape does not guarantee correct content.
The shortcut
Four beats: schema in, parse, check, retry. If the retry also fails, fall back to a person.
Schema in
The request includes the email plus the field definitions and allowed values.
The trap is trusting output because it parsed. Valid JSON with a made-up order number is still wrong, which is why the schema must permit null. Retries also cost an extra call, so log how often they happen; a rising retry rate is an early warning that something has drifted.
Drills
Answer fast — trust the rule.
Why limit category to a fixed list of values?
An email mentions no order. What should the schema allow for order_id?
The model returns valid JSON but urgency is "super urgent". What happens next in the four beats?
The API enforces your JSON schema. Do you still need your own checks?
Remember
- If code will read it, ask for a schema, then validate.
- Schema in, parse, check, retry, then a person.
- Allow null; valid JSON is not the same as true JSON.