How to Use the OpenAI Structured Outputs Schema Prompt to Ship Extractors That Fail Closed

Free form JSON from a model is fine until an invoice number is invented and your AP inbox trusts it. Structured Outputs in strict mode only helps if the schema, the Pydantic model, and the fixtures agree. The OpenAI Structured Outputs Schema Designer: JSON Schema Strict Mode, Refusal Paths, Pydantic Models, and Evaluation Fixtures prompt designs that trio: a strict JSON Schema, a matching runtime model, refusal paths for missing identifiers, and tiny evaluation fixtures you can run before production traffic.

What the prompt produces

1. A JSON Schema draft with additionalProperties false, required arrays, and typed properties.
2. Strict mode notes on nullable fields versus required fields and how to represent unknown without guessing.
3. A parallel Pydantic or Zod model that mirrors the schema field for field.
4. A wiring sketch for response_format style calls with confirm gaps for exact SDK parameter names.
5. Refusal and incompleteness paths so the model returns structured status instead of hallucinated IDs.
6. Evaluation fixtures including one adversarial input tied to your known failure modes.
7. A validation outline that parses, repairs once, then fails closed to a human queue.
8. A schema changelog line so product can bump versions without silent breaks.

How to fill the inputs

JobBrief should describe the extraction or routing job in one paragraph. Invoice headers, ticket triage, and lead routing all work if the fields are clear.

FieldSpec lists required fields, optional fields, and enums. Enums beat free text for categories your product already knows.

ModelFamily can be a class name. Do not ask the prompt to invent release dates or pricing.

FailureModes should be failures you have already seen: invented IDs, dollars versus cents swaps, empty arrays when tables exist.

Runtime chooses Pydantic v2, Zod, or schema only. Matching types across languages is where silent drift starts.

Reading the example output

The sample extracts invoice headers for an AP inbox.

• invoice_number is nullable with status incomplete when missing, which blocks invention.
• total_cents is an integer, so $12.34 becomes 1234 instead of a float surprise.
• Fixtures include an adversarial "make up a number" input that must stay null.
• Validation repairs once, then fails closed, which is the production posture you want.

Tips for better results

• Write fixtures before you wire the SDK call. If fixtures fail, the schema is wrong.
• Version the schema name in the payload so old clients do not silently accept new required fields.
• Keep refusal as a first class status enum, not a side channel string in a comment.
• Re run fixtures whenever you add a field, even a "small" optional one.
• Log schema validation errors with the raw model text for a week while you tune.

Mistakes to avoid

• Do not invent token prices, rate limits, or model launch dates.
• Do not allow additionalProperties true in strict extractors.
• Do not retry forever on validation errors. One repair, then human review.
• Do not treat Structured Outputs as a substitute for checking business rules like totals matching line items.

Who it is for

Applied LLM engineers and platform teams shipping extractors into ops tools where a wrong field costs real money.

When product asks for one more optional field, add it in a versioned schema and extend the fixtures in the same pull request. Schema drift without fixtures is how incomplete status quietly turns back into invented strings in production.

Keep a single owner for the schema changelog so two teams do not ship v2 and v3 on the same day.

Related PromptDig links

Open the OpenAI Structured Outputs Schema Designer: JSON Schema Strict Mode, Refusal Paths, Pydantic Models, and Evaluation Fixtures prompt with your field spec and failure modes. For more AI engineering prompts, Browse more prompts. If you have a fixture pack that caught a hallucination in staging, Share a prompt.