Structured outputs change what clients are really buying when they ask to automate messy intake. For a long time, these projects were framed as prompt-writing exercises: take emails, PDFs, forms, or copied text and extract the fields. In production, the expensive part was usually the cleanup afterward. You could get valid-looking JSON and still have the wrong record, with missing keys, odd nesting, or output that broke the moment it hit a CRM, spreadsheet, or back-office workflow. The practical read on OpenAI's current documentation is that schema reliability is now much stronger, which shifts the work. The hard part is no longer coaxing the model into roughly the right shape. It is defining the record properly, choosing the right model, and making sure bad data does not leak into live systems.
Structured outputs make the schema the product
OpenAI's guide draws a clear distinction between older JSON mode and structured outputs. JSON mode can force valid JSON, but structured outputs are the feature meant to enforce adherence to a supplied schema, and the guide recommends using them instead of JSON mode where possible. The product announcement explains why this matters: OpenAI combined model training with deterministic constrained decoding so responses can be forced to follow the schema you provide. In OpenAI's published evals for the launch-era implementation, strict structured outputs achieved perfect schema matching on the benchmark it reported, while an older tool-capable model was materially less reliable.
That changes the commercial shape of the work. Once the output format is dependable enough for production use, the value moves upstream and downstream. Upstream, someone still has to define the canonical record. Downstream, someone has to validate it, route exceptions, retry failures, and stop questionable data before it lands in operational systems. So the offer is no longer, 'we'll write a better prompt.' It becomes, 'we'll design and run an intake pipeline your team can trust.'
The docs still leave plenty of engineering work
The useful thing about the structured outputs guide is that it does not pretend the feature removes engineering effort. OpenAI says it supports much of JSON Schema, not all of it. Some schema features are unavailable for performance or technical reasons, and unsupported schemas can error when strict: true is enabled. The guide also documents hard limits on schema size and nesting depth. In practice, that means a real intake project starts by trimming the data model down to something the API can actually enforce, instead of trying to pass through every edge case the business has accumulated over time.
The same guide also forces discipline in how objects are designed. The root object must be an object, not a top-level anyOf, and object fields are expected to be required. If a value may be absent, the documented pattern is to model that explicitly, often by allowing null rather than silently dropping the key. The guide also notes that output keys are returned in schema order, which helps when logs, audits, or post-processing depend on predictable structure. These sound like small implementation details, but they are exactly the details that decide whether finance, operations, or support will trust the automation.
OpenAI's docs are also fairly clear about pattern choice. If the model needs to bridge into your own tools, functions, or data layer, function calling is the right approach. If you want the model to return structured data directly, use a schema-based response format. For intake automation, that distinction matters. A workflow that reads inbound material and then writes records into a CRM or internal API will usually want strict function calling. A workflow that just hands normalized data to the next step may be better served by schema-constrained response output.
There are still failure modes to design around. The product announcement notes that the first request with a new schema carries extra latency because the schema has to be processed before reuse. It also notes that structured outputs can still fail when a request is refused for safety reasons or when generation stops before completion. The same announcement warns that strict structured outputs are not compatible with parallel function calls, so production flows that depend on tool calls may need parallel_tool_calls: false. That is why serious delivery includes schema warm-up, validators, retries, and a human-review queue instead of a single API call wired directly into production.
Model choice is an operations decision, not a branding decision
The current model pages make the tiering logic fairly practical. GPT-5.5 is positioned as OpenAI's newest frontier model for the most complex professional work, with structured outputs support, the highest reasoning classification on its page, a 1,050,000-token context window, and pricing of $5 input and $30 output per 1 million text tokens. That is the tier to consider when the source material is messy, the classification calls are nuanced, or the cost of a wrong extraction is high enough that extra reasoning is worth paying for.
The compare-models page also makes the middle tier easy to place. GPT-5.4 is described there as a more affordable model for coding and professional work, still with structured outputs support, the same 1,050,000-token context window, and pricing of $2.50 input and $15 output per 1 million tokens. For a lot of back-office automation, that is a sensible balance: enough capability for complicated documents without paying frontier-model rates on every record.
At the high-volume end, GPT-5.4 mini is the clearest operational play. Its model page describes it as a faster, more efficient option designed for high-volume workloads, with structured outputs support, a 400,000-token context window, and pricing of $0.75 input and $4.50 output per 1 million text tokens. If the workflow is processing large numbers of routine emails, forms, or repeatable intake records, mini is often the tier that keeps unit economics under control. The practical rule is simple: match model spend to the cost of being wrong, not to the excitement of putting the flagship model everywhere.
What a paid data-cleanup project actually includes
- Source mapping. Identify every intake source, every field that matters, and every ambiguity that already exists before AI touches anything. If two systems use different names or meanings for the same field, that needs to be resolved in the schema, not left for the model to guess.
- Schema design. Define one strict JSON contract for the record downstream systems should receive. Keep it compatible with OpenAI's supported schema subset and version it like any other production interface.
- Model tiering. Assign GPT-5.5, GPT-5.4, or GPT-5.4 mini based on document difficulty, acceptable error rate, throughput, and token economics. Reserve expensive reasoning for exceptions, edge cases, or high-value records.
- Validation and retry logic. Treat schema conformance as necessary but not sufficient. Validate business rules after parsing, retry when the problem is transient, and route unresolved cases into a review queue.
- Integration controls. Use function calling when the workflow has to bridge into internal tools or APIs, and add explicit approvals or human review where a bad write would be costly. Clean output only matters if it reaches the right system in the right state.
The important limit: structure is not the same as truth
This is where many buyers still get tripped up. Structured outputs remove a major class of failure: malformed or schema-breaking output. They do not guarantee that every extracted value is semantically correct. OpenAI's own announcement is explicit on that point: a model can still be wrong inside a perfectly valid structure. That is why the strongest intake automation projects are not sold as abstract 'AI extraction.' They are sold as controlled data-cleanup systems with measurable acceptance criteria, escalation paths, and clear operational ownership.
That is where Greg is useful. Not as someone claiming a magic prompt, but as an operator who can help turn messy intake into a working pipeline: map the sources, define the strict schema, choose the right model tier, add validation and retry logic, and connect the cleaned output to the client's actual systems with human-review fallbacks where needed. If a client says they want intake automated, the sensible first step is to scope the data contract and cleanup workflow before anything goes live. The current OpenAI docs suggest that is where the real value now gets created.
Need help with this kind of work?
Map your intake workflow Get in touch with Greg.