Structured Outputs: Get the Same Shape Every Time

Reliable drafting starts with shape, not eloquence. If you can already write a clear prompt, this guide takes the next step: making a repeated task return the same fields, in the same structure, every time. If prompting itself is still new, start with Prompt Engineering Fundamentals 2026 and bring back one repeated task that produces a list, table, form or record.

The problem: every useful answer needs tidying

Ask an AI assistant for an action list ten times and the content may be useful ten times. The shape may still wander. One answer uses a table. The next adds a preamble. A third turns missing dates into plausible dates. A fourth renames "Owner" as "Responsible person", which breaks the spreadsheet import waiting downstream.

That variation is tolerable in a conversation. It is expensive in a workflow.

Repeatable work depends on an output contract: the fields, types, allowed values and missing-information rules that every response follows. Structured outputs apply that contract so another person or system knows where each item belongs.

OpenAI introduced Structured Outputs in the API to make model responses conform to developer-supplied JSON Schemas, and distinguishes that feature from JSON mode, which produces valid JSON without guaranteeing a particular schema. Anthropic's structured outputs for the Claude API offer two related controls, JSON outputs that constrain the response format and strict tool use that guarantees schema validation on tool inputs, both delivered through constrained decoding.

The important word is shape. Structured output can ensure that a due-date field exists and contains either a date or a permitted null value. It cannot ensure the date is true. Format reliability and factual reliability are different controls.

The core concept: an approved form for AI

Think of an approved incident form. Every form asks for the same fields in the same order. It may require an incident date, location, category and reviewer. The form does not guarantee the person entering the details is correct. It makes missing and inconsistent information easier to see, validate and route.

A structured output is that form for a model.

There are three levels, and confusing them creates false confidence.

Level 1: a prompted template

The prompt says: "Return a table with Action, Owner, Due date and Review flag." Most modern assistants will usually comply. This is accessible in ChatGPT, Claude, Gemini or Copilot and works well for human-reviewed drafting.

It is still an instruction. The model may add prose, rename a column or omit an empty field. Anthropic's output consistency guidance recommends precisely specifying the desired format for flexible outputs, but directs developers to schema-constrained structured outputs when guaranteed schema conformance is required.

Level 2: valid JSON

JSON is a text format built from objects, arrays, names and values. A response can be valid JSON but still have the wrong fields. {"person":"[EMPLOYEENAME]"} and {"owner":"[EMPLOYEENAME]","duedate":null} are both valid JSON. Only one may match your workflow.

Level 3: schema-constrained output

A JSON Schema defines the permitted structure. It can require fields, restrict a value to an approved list, set types and reject additional properties. The JSON Schema project describes it as a declarative language for defining the structure and constraints of JSON data.

When a supported API uses constrained decoding, the system limits generation to tokens allowed by the schema. That is materially stronger than asking politely for JSON. It gives software a parseable contract.

It still does not verify meaning. "duedate":"2026-08-14" can satisfy the schema and be unsupported by the notes. A source check and human review remain necessary.

Putting it to work: the SHAPE workflow

Use the SHAPE workflow to convert a repeated draft into an output contract.

S: Select the downstream job

Name what happens after the output. Will a person paste it into a register, will an automation create tasks, or will a reviewer compare it with a source document?

The stricter the downstream action, the stricter the contract and validation must be. A human-readable briefing can tolerate an optional note. An automated payment or employee decision should never depend on an unchecked model value.

For this example, the named workflow is Meeting Notes to Action Register. Its output feeds a draft register. A person confirms every item before import.

H: Hold the minimum fields

Choose only fields the next step needs:

• action
• owner
• duedate
• sourceevidence
• reviewstatus

Do not add fields because they might be useful later. Every field increases ambiguity, testing and maintenance. Keep narrative context in one clearly labelled notes field if it is genuinely required.

A: Assign types and allowed values

Decide whether each field is text, number, true or false, a list, or an object containing more fields. Use a controlled vocabulary where variation would create downstream work.

For reviewstatus, allow only:

• readyforhumancheck
• missinginformation
• conflictdetected
• outofscope

Avoid free-text status labels such as "looks fine". Stable labels can be filtered, counted and routed.

P: Plan for missing and conflicting evidence

Missing information is normal. Design for it.

Choose one rule: either permit a true null value, or require an explicit status plus an empty field. Do not let the model substitute "TBC", "unknown", "n/a" and a guessed value across different runs.

Conflict deserves its own path. When two due dates appear, preserve both in sourceevidence, leave duedate null and set reviewstatus to conflictdetected. The structure should make uncertainty visible rather than force a false answer.

E: Evaluate the contract

Test at least these conditions:

1. all fields present in a clean input
2. owner missing
3. due date missing
4. two conflicting due dates
5. discussion that is not an action
6. real personal information supplied by mistake
7. extra commentary requested by the user
8. very long notes that risk truncation

Check both schema validity and factual support. A parser can test whether the shape is correct. A person or source-grounded check must test whether each value is justified.

Choose structure by consequence

Not every repeated task needs an API implementation. Use the lightest structure that supports the next decision.

A prompted table is often enough when one person reads a small number of outputs and nothing happens automatically. A validated spreadsheet import may justify machine-readable JSON plus a separate validation step. An application that creates records or calls tools needs a schema, error handling and a permission boundary around the action.

Ask four questions before increasing technical complexity:

1. Volume: how many outputs must another person or system handle?
2. Consequence: what happens if a field is missing or wrong?
3. Reversibility: can the next action be easily reviewed and undone?
4. Evidence: can the reviewer see the source behind every important value?

If volume is low and consequence is high, a structured draft plus careful human review may be better than automation. If volume is high and fields are objective, schema-constrained extraction can remove formatting work while leaving meaning checks in place.

Also decide which information belongs outside the model response. The workflow run ID, model version, prompt version, source identifier, validation result and reviewer decision are usually operational metadata. Store them in the surrounding system rather than asking the model to invent or repeat them. This creates a cleaner audit trail and prevents a fluent response from masquerading as system evidence.

Finally, define what happens when validation fails. Do not silently coerce an invalid value into something that passes. Route it to a review queue, preserve the original response and record the reason. A visible exception is safer than a clean field that changed meaning.

The mistake to avoid: treating a valid field as a true fact

Do not confuse "the response parsed" with "the response is correct".

OpenAI explicitly notes that Structured Outputs can still contain mistakes inside the values, even when the object matches the schema. Anthropic likewise documents exceptions where the response may not match the requested schema at all, including safety refusals and responses cut off by the maxtokens limit.

That creates four separate checks:

• Shape: Does the response match the required structure?
• Support: Is each value grounded in the supplied source?
• Permission: Is the workflow allowed to use that data for this purpose?
• Decision: Has the authorised person reviewed what must remain human?

A schema is a control for the first question. It does not answer the other three.

Another common mistake is copying personal information into field names, examples or schema descriptions. Schemas are reusable configuration. Keep them generic. Use placeholders such as [EMPLOYEENAME] and test with fictional data.

Worked example: a consistent draft in ChatGPT

This prompt uses a visible contract in ChatGPT. It improves consistency but does not create an API-level schema guarantee.

You are an action-register extraction assistant.

Task: Extract explicit commitments from the fictional or de-identified meeting
notes. A human will confirm every item before the draft enters the register.

Return only a JSON array. Use exactly these fields for every item:
- action: string
- owner: string or null
- due_date: YYYY-MM-DD string or null
- source_evidence: exact short phrase from the notes
- review_status: one of ready_for_human_check, missing_information,
  conflict_detected, out_of_scope

Rules:
1. Never infer an owner or date.
2. If two dates conflict, use null for due_date and conflict_detected.
3. Do not convert discussion or suggestions into commitments.
4. Do not add fields, headings, commentary or markdown fences.
5. If real personal information appears, stop and request de-identification.
6. If evidence is missing, say so through the fields. Do not invent it.

Meeting notes:
{{PASTE FICTIONAL OR DE-IDENTIFIED NOTES}}

Use this fictional input:

[EMPLOYEE_NAME] will update the draft procedure. The group discussed training.
The notes list 14 August and later 18 August as the procedure due date.

A satisfactory result has one action, no training action, a null due date, evidence showing the conflict and conflictdetected as the status.

If the output will feed code, move the same contract into a supported API schema. That is the advanced control. If it stays in a human-reviewed chat, keep validation manual and do not describe the shape as guaranteed.

For a broader workflow build, use Your First AI Workflow Without Code. For a practical document pipeline, see Turn a Teams Transcript Into a Controlled SOP.

Going deeper: schema design is process design

The advanced layer is less about JSON syntax than organisational decisions.

Required fields express what the workflow refuses to leave ambiguous. Enumerations express approved states. Null rules express how missing evidence is handled. Additional-property rules express whether the model may improvise. The schema becomes a compact version of the process policy.

A simple schema fragment for one action might look like this:

{
  "type": "object",
  "properties": {
    "action": {"type": "string"},
    "owner": {"type": ["string", "null"]},
    "due_date": {"type": ["string", "null"]},
    "source_evidence": {"type": "string"},
    "review_status": {
      "type": "string",
      "enum": [
        "ready_for_human_check",
        "missing_information",
        "conflict_detected",
        "out_of_scope"
      ]
    }
  },
  "required": ["action", "owner", "due_date", "source_evidence", "review_status"],
  "additionalProperties": false
}

Supported schema features differ by provider and model. Check current official documentation before implementation. Also plan for refusal, truncation, timeouts and provider errors outside the model's normal structured response. Production reliability needs error handling around the contract, not just a contract inside it.

Version the schema. A renamed field can break downstream systems even if the new name reads better. Treat schema changes like process changes: document them, test old and new inputs, update consumers and keep a rollback path.

This article provides general educational information only. Verify current provider capabilities against official documentation, and seek advice from suitably qualified professionals before relying on structured outputs in regulated or high-consequence workflows.