A Valid JSON Answer Can Still Be Wrong

A retrospective starting point

On August 6, 2024, OpenAI announced Structured Outputs for its API. This is retrospective coverage of that announcement and its practical lesson, not a new release report or a current API compatibility guide. The distinction remains useful even as specific product details change: a response that fits a schema has passed a formatting and structure check, but it has not thereby passed a truth check.

Imagine asking an AI system to extract action items from meeting notes. One note says: “Maya will send the revised budget by Friday. Leo will ask whether the launch review can move to next Tuesday.” A system returns a JSON object containing two tasks and due dates. It is valid JSON. It may also fit a developer’s schema exactly: each task has a string description, an owner, and a date. Yet the system might assign Tuesday to Maya’s budget task. The shape is right; the association is wrong. This is a hypothetical example, not a reported customer incident.

That difference matters whenever structured output feeds a spreadsheet, case-management system, workflow, or another program. Reliable parsing prevents one class of failure: a receiving program can read fields in expected forms. It does not settle whether those fields faithfully represent the source. A useful mental model keeps four questions separate: Is the response valid JSON? Does it conform to the supported schema? Are its values correct and grounded in the input? Is the system permitted to use those values for the next step? Each question needs its own evidence and checks.

What constrained decoding changes

OpenAI’s 2024 explanation describes Structured Outputs as using constrained decoding alongside model training. In ordinary generation, a model selects the next token from possible tokens. The company’s account says that, with a supplied schema, its system converts the schema into a context-free grammar and uses the generated prefix to determine which next tokens are allowed. It then masks the other tokens for that sampling step. In plain terms, the allowed continuations narrow as the response is produced, helping keep the output inside the format described by the grammar.

Consider a required object with a numeric value field and no extra properties. At the start, many tokens could begin a response. After the opening characters identify a key, some continuations no longer fit the grammar. The system can rule out those continuations as it generates. This is more than asking a model to “please return JSON” and hoping it does. It is a technical constraint on output generation, as described by the vendor.

The distinction from plain JSON validity is important. A JSON parser can accept an object with the wrong keys or missing required fields. Schema validation can reject those structural mismatches when the schema and validator are correctly applied. Structured decoding aims to guide generation so that output matches a supported schema. These mechanisms make incompatible shapes less likely or detectable; they do not establish that an allowed string names the right person, that a date was present in the notes, or that a numeric amount was calculated correctly.

The announcement also names limits. It says Structured Outputs supports a subset of JSON Schema, and that a refusal or generation interrupted before completion can produce a response that does not match the requested schema. It describes a refusal signal and an interruption indicator in the 2024 API response. Those details are historical documentation, not a promise about today’s endpoint, model names, SDK behavior, or exact response fields. The current guide could not be retrieved for this article, so check current primary documentation before implementing against an API.

Four checks, four different jobs

JSON validity asks whether the bytes or text can be parsed as JSON at all. A missing closing brace or trailing comma can make the text unusable to a strict parser. Parsing should happen before code assumes it has an object with fields.

Schema conformance asks whether the parsed value has the required structure and types under the schema being applied. A schema might require a list of tasks, each with an owner and a date represented as a string, and prohibit additional fields. A validator can report that a field is absent, has the wrong type, or violates a declared constraint. Conformance is relative to that schema. A permissive schema can accept content that a stricter application would reject, and an unsupported schema feature cannot be assumed to have been enforced by a constrained-generation system.

Factual accuracy asks whether the values match the source and the real-world facts the application cares about. A string such as 2024-08-06 can be perfectly well formed and schema-valid while attached to the wrong task. A required field can contain a plausible guess. A permitted category can still be the wrong category. Validation needs to compare extracted fields with their evidence, and uncertainty needs a representation the application can preserve rather than silently convert into a confident value.

Permission to act asks whether a person or system is allowed to take the proposed step. Even a factually correct task and date do not grant authority to send a message, change a calendar, approve a payment, or update a record. That requires application-level authorization, such as checking the signed-in actor, their role, the object’s access policy, and any required confirmation. A schema can describe an action request; it cannot confer permission.

A practical review for extracted fields

For the hypothetical notes, first keep the source text available with the extraction. Review each field, not only whether the whole object validates. Ask: does “Maya” appear as the owner of the budget task? Does Friday belong to that same task? Is Tuesday explicitly associated with the launch review, or was it inferred from a nearby sentence? A reviewer should be able to trace each field to the words that support it.

If a note does not say who owns a task, represent the owner as unknown or absent according to the application’s explicit rules. Do not ask the model to fill a required string with a guess just because the schema requires a string. If the schema cannot represent missing or uncertain information, revise the application’s data model before relying on it. A field such as evidence_span, confidence_status, or a nullable value may help, but those labels are useful only when their meaning is defined and checked. A confidence number is not proof either.

Next, validate mechanically. Parse the response. Check it against the exact schema the application expects. Reject incomplete, refused, or interrupted results using the current interface’s documented signals. Preserve the original source and validation outcome in a way appropriate to the data’s sensitivity. Then perform field-level review or other independent checks suited to the consequences of error. For high-impact decisions, a human may need to confirm the result before it can change external state.

Finally, authorize separately at the moment of action. The application should decide whether the user and workflow may perform the requested operation, whether the target object is in scope, and whether confirmation is required. Do not treat a well-formed send_email object as permission to send email. Keep the output as a proposal until policy and identity checks pass. These are general engineering considerations, not a description of verified OpenAI safeguards or of any particular customer system.

What the 2024 result does and does not say

OpenAI reported that gpt-4o-2024-08-06 achieved 100% on the company’s evaluation of complex JSON Schema following. That statement concerns a vendor-described evaluation of schema adherence for a named 2024 model and feature. It does not show that every generated value was factually correct, that every schema or application is supported, or that a business workflow achieved a successful outcome. It is not a universal accuracy rate. The central practical claim does not need the score: constraining output can address format and structure, while application teams still need to evaluate meaning and action safety.

This is also why demos should be read carefully. A response that parses and passes a validator proves those checks passed for that response under the schema and validator used. It does not establish that the model read the source correctly. A successful extraction test on one example does not establish performance on every document, language, formatting variation, or ambiguous instruction. Test representative cases, include missing and conflicting information, and record which kinds of error the system can detect.

The durable boundary

Schema-constrained generation is valuable because predictable structure can make software integration less brittle. It can move some formatting errors out of the application’s critical path. The boundary is equally important: structured output is a container for claims, not proof of those claims. A sound workflow verifies parseability, schema support and conformance, source-grounded values, and authorization as distinct steps. It preserves uncertainty and gives people a meaningful opportunity to correct consequential mistakes.

For historical context, OpenAI’s announcement explains its 2024 method through token masking and a schema-derived grammar, while also warning that values may still contain mistakes. Product behavior can change, so current implementation details should come from current documentation. The reader-facing lesson does not depend on a particular API: a well-shaped answer can still be wrong, and a correct answer still needs permission before anyone acts on it.