Schema Lock vs Tool Contract: OpenAI Wins the Compliance Read

A compliance lead at a mid-size UK financial services firm described her problem last month without any particular drama. Her ETL agents were returning valid JSON. But valid JSON is not the same as correct JSON. One missing field in a transaction record, three days before anyone caught it. The audit question that followed was not pleasant.

Her situation has a name now. It has two vendor answers. And the two answers are not interchangeable.

OpenAI's Structured Outputs feature locks JSON schema adherence at the model level, enforcing it so tightly that a missing required key is simply not possible in a compliant response. Anthropic routes the same goal through tool use, where JSON conforming to a tool input schema is the output contract. Same destination. Different trust layers. Different failure modes.

For a small team building internal automations, the difference rarely surfaces. For anyone processing regulated data at volume, the difference is where the audit starts.

The Deployment

Structured Outputs is available through two mechanisms in the OpenAI API: via function calling, and via the response_format parameter in the Chat Completions API (or text.format in the Responses API). The distinction matters. Function calling is for when the model needs to bridge to external tools or data. The response_format path is for when you want the model's output itself to conform to a schema, not just be valid JSON.

The enforcement is strict by design. Pass response_format: { type: "json_schema", json_schema: {"strict": true, "schema": ...} } and the model guarantees schema adherence. Not "usually adheres." Guarantees. Required keys are present. Enum values are valid. The model cannot omit a field and return a passing response.

The SDK surface for Python leans on Pydantic; for JavaScript, Zod. You define the schema in code, pass it to the completion call, and the parsed result comes back typed. No validation layer on top. No retry-on-malformed logic. The contract holds at the source.

Two other things come along with the feature. Explicit refusals: when the model declines to answer for safety reasons, that refusal is now programmatically detectable rather than buried in a text string you would otherwise have to parse. Simpler prompting: you stop needing strongly-worded instructions in the system prompt to enforce output format, because the format is enforced below the prompt layer entirely.

JSON mode, the older predecessor, also guarantees valid JSON. It does not guarantee your schema. That distinction is small in a demo. In production, at two in the morning, with a pipeline that has been running for six hours, it is everything.

[[IMG: a developer reviewing a structured JSON schema definition on two monitors in a low-lit office, late evening, code editor open with Pydantic model visible]]

Why It Matters

The comparison with Anthropic's approach is not a product-feature skirmish. It is an architectural question about where trust lives in your stack.

Anthropic's tool use mechanism returns JSON that conforms to the tool input schema you define. The shape is enforced through the tool contract. The failure mode sits in a different place: if the tool schema is underspecified or mismatched against what the model infers the task requires, you can get a conforming-but-wrong response. The model did what it was told. The schema passed. The downstream record is still wrong.

OpenAI's Structured Outputs moves enforcement lower. The model itself cannot produce a response that violates the schema you supplied. The audit trail is cleaner because the failure mode is explicit: either the schema was wrong, or the model refused, and both states are detectable.

For ETL agents in UK financial services, or for form-filling pipelines under EU GDPR constraints, the audit trail question is not theoretical. Regulators want to know what the system was instructed to produce and whether the output matched. A system where the model could silently drop a required key is a system with an audit gap. Structured Outputs closes that gap at the architecture level, not the testing level.

The compliance lead I mentioned was not asking for a better model. She was asking for a different trust contract. One where the schema is not advisory.

This is where the two approaches diverge most sharply. Neither is wrong in the abstract. Anthropic's tool use is capable and works well for a wide range of agent architectures. But the regulated-industry operator who needs to prove, in writing, that a missing field was architecturally impossible will find the Structured Outputs enforcement model substantially easier to defend.

The vendor pattern this echoes is any moment in software history where validation moved down the stack, closer to the source of truth. Database constraints over application-level checks. Typed languages over runtime validation. Schema enforcement at the model level is the same move, one layer further down. Once you have seen that pattern work, advisory validation starts to feel like a liability.

What Other Businesses Can Learn

If you are building agent-based workflows that touch structured data, the choice between JSON mode and Structured Outputs is not cosmetic. It is where your compliance posture lives.

The first thing to establish is which API path you are on. OpenAI surfaces two primary routes. The Chat Completions API uses response_format; the Responses API uses text.format. Functionally similar for Structured Outputs purposes, but you need to pick one and maintain it consistently. Mixing them inside the same pipeline creates two different surfaces to audit and two different places for the schema contract to silently drift.

The second consideration is model pinning, and it matters here more than in most contexts. Structured Outputs is available from gpt-4o-mini and gpt-4o-2024-08-06 onward. Older model snapshots fall back to JSON mode. JSON mode does not enforce your schema. If your pipeline drifts to an older snapshot during a routine dependency update, your schema guarantee disappears without surfacing a single error. Explicit pinning is not optional. Review the pin whenever you update.

Third: the function-calling path versus the response_format path have different intended uses. Function calling is for bridging the model to your application's tools and data. The response_format path is for structuring what the model returns to the user or passes to the next pipeline stage. They look similar in code. They are not the same design choice. Teams that conflate them early accumulate integration debt that surfaces precisely when they need to add audit logging before a compliance review.

Fourth, for teams on Anthropic: tool use schema enforcement is real and capable. It is not the same enforcement model. Before you deploy to any regulated workflow, run adversarial inputs against your tool definitions. Find the edges of where the contract can be underspecified. The failure mode is not absent; it is located differently, and locating it before production is the audit pass that saves a Tuesday afternoon.

The audit question is not whether your JSON is valid. It is whether valid JSON was the only possible output given the instruction you supplied.

This is the frame that separates the operators who sail through compliance reviews from the ones who do not. Structured Outputs answers that question with a yes at the architecture level. That is a different kind of confidence than any prompt engineering workaround provides.

[[IMG: a compliance officer at a regulated UK financial services firm reviewing an AI agent audit log on a laptop, open-plan office, natural afternoon light through large windows]]

Looking Ahead

The near-term signal to watch is whether Anthropic adds a lower-level schema enforcement mechanism that matches OpenAI's strict mode guarantee. Tool use schema contracts are enforced contractually at the call boundary; model-level enforcement is a different architectural decision, and whether that gap matters to a given buyer depends almost entirely on the regulatory environment they are operating in.

The longer signal is more interesting. JSON schema enforcement at the model level is not the ceiling. Once the output contract is reliable, the next question becomes whether the model's reasoning toward that output is also auditable. That conversation is already in procurement discussions at regulated institutions. Structured Outputs gets you to the right output shape. It does not yet tell you how the model got there.

The compliance lead from the beginning of this piece, when I asked the obvious follow-up, gave me the same answer I have now heard from several operators this quarter: the schema is the easy part. The reasoning trace is what they want next.

• OpenAI Platform Docs, Structured Outputs, accessed 2026-04-27