Technique
Schema first, prompt second
Building with it A few minutes First logged
- InA step that must return machine-readable data
- ThenSend a schema as a parameter instead of asking in words
- OutA shape you can put in the middle of a pipeline
What the move is
Write the output schema before the instruction. The prompt then only has to describe the judgement, because the shape is already enforced.
Why it works
Asking for JSON is a request; supplying a schema is a constraint. Once the shape is guaranteed, the prompt gets shorter and clearer because it stops describing formatting.
Step by step
- Write the schema as the definition of the step's contract, flat rather than deeply nested.
- Pass it as the structured-output parameter, not as text in the prompt.
- Write the instruction about the decision only: what counts as this field being true.
- Handle refusal, safety rejection and truncation as separate branches from parse failure.
- Validate values at the boundary anyway.
Paste this
The schema is on the request, so do not restate it or put text around the object. Judge one thing: <what makes each field true>, from <the source> and nothing else. If a value is not there, set notFound rather than inventing one.
Make it yours
Add a required 'confidence' or 'notFound' field so the model has a legal way to say it does not know, instead of inventing a value to satisfy the shape.
Variations
- Add an 'evidence' string field holding the quote the value came from.
- Make every optional field required with an explicit null instead.