A perfectly valid JSON object can still invent a library pickup time. This guide treats that distinction as the core design challenge for OpenAI Structured Outputs: request a predictable schema while allowing an unknown value to remain null until someone checks a calendar. The fictional request, dates and responses are for teaching only. We have not run a model, connected a booking system or confirmed an appointment. The graphics show a proposed verification path, not screenshots or benchmark outcomes.
Separate the shape of a request from its truth
A library volunteer receives a fictional message: “Could I collect the repaired book on Thursday? Please tell me what time works.” The message mentions a date but contains no confirmed pickup time. An AI extraction pipeline may be expected to create a tidy record, but a neatly formatted time such as 2:00 PM would be invented.
OpenAI Structured Outputs can require a predictable JSON structure; it cannot establish an appointment that nobody approved. Treat model output as a proposal for review, not a booking transaction. The figures use made-up records and are not model responses observed in testing.
Select Structured Outputs instead of relying on JSON mode
OpenAI documentation distinguishes simple JSON validity from schema adherence. For supported models and interfaces, Structured Outputs constrains responses to a defined JSON schema.
In the Responses API, the documentation shows a text.format configuration for json_schema and strict mode, while other API surfaces use different parameter placement. Do not copy a response_format example from Chat Completions into a Responses request without adapting it. The feature changes the expected format, not whether extracted facts were present in the input or checked against a database.
Make absence an explicit part of the schema
Use a required pickup_time property whose allowed type includes string and null. The official guide states that all properties must be required in strict schemas; a union with null represents a value that may be absent. Do not force a non-null string when the source did not specify a time.
Another field can record a status such as requested, awaiting_staff_confirmation or confirmed, but the application must assign “confirmed” only after checking the scheduling system. These are example business labels, not predefined OpenAI output statuses. Leave unknown or unsupported details visibly unknown.
Keep the strict JSON subset genuinely supported
Strict Structured Outputs supports a subset of JSON Schema and requires additionalProperties: false for objects. The schema root must be an object rather than an anyOf union, and optional-looking fields should still appear in the required list with nullable types.
A configuration that violates the supported subset can fail before a useful extraction result is generated. Put business rules in application validation as well: a valid time string, even if it matches a schema, is not evidence of staff availability. Use a schema linter and ordinary tests to keep code types aligned with the JSON contract.
Illustrate the data flow without claiming an API run
The process drawing starts with a visitor request, proceeds through a strict extraction schema, then a record showing pickup_time: null, and finally a staff confirmation boundary. The model does not call the library calendar or confirm a collection slot merely by returning conforming JSON.
The system can display the proposed date, unknown time and the relevant message for human review. Only a separate authorized operation should update the appointment record, with a unique request ID to avoid creating duplicate reservations on retries. These steps are workflow recommendations, not measured product behavior.
Compare a hallucinated field with honest uncertainty
One side of the comparison panel shows a fabricated 2:00 PM assignment despite the user supplying no time. The other shows pickup_time set to null and status awaiting_staff_confirmation, together with a visible action for the library coordinator.
The difference is not whether the JSON is well formed; both objects could satisfy an overly permissive schema. The reviewed design encodes the missing fact without filling it. Use transcript citations or message references in the application’s audit record so the coordinator can check where each value came from.
Handle refusal, incompleteness and parser failures
The official OpenAI guide notes that refusals and incomplete outputs can prevent an otherwise strict schema from yielding the expected data. A robust client must inspect response status and refusal indicators before assuming the usual parsed object exists.
It also needs to handle network errors, unsupported schemas and output-size interruptions. An application should not interpret an absent parsed response as pickup_time null by default: that would erase the distinction between a genuine missing time and an extraction failure. Keep explicit error states, retries with idempotent identifiers, and a manual queue.
Treat source evidence and external actions separately
If a visitor says “I asked about Friday yesterday,” the system still needs a timestamp, message history and access to the official booking source to determine what is current. Schema-constrained output can preserve fields such as source_message_id, requested_date and pickup_time, but it does not authenticate those fields.
Validate against allowed library hours and the live appointments database only with authorized access. Avoid sending personally identifying information to services without policy approval. Make sure public-facing replies never claim that a request is confirmed until the authoritative system reports that status.
Audit four fields on the final review screen
The visual checklist marks required schema fields, the null value, extraction status and staff approval. Construct tests from fictional examples: date only, time only, contradictory messages, an unknown date, a refusal, and a retry after a timeout.
Verify that the UI shows unknown fields clearly and that no automated notification says a pickup is booked before the confirmation step. Review every schema change against typed client models so a new required property does not silently break a downstream importer. Do not describe those hypothetical test cases as executed test results.
Document responsibility for factual confirmation
Record the selected model, request interface, schema version, validation rules, source-message references, human approval process and failure handling. Recheck the OpenAI documentation for supported models and schema keywords when upgrading.
The article does not call the API, store personal requests, or create library appointments. It explains why strict data shape is useful while insisting on an independent confirmation step. The key editorial distinction is simple: a required field with a null value can be more accurate than a fabricated but syntactically valid answer.
How We Research
For this November 2026 guide, we consulted vendor-maintained references: OpenAI API: Structured model outputs, OpenAI: Structured outputs in the Responses API, OpenAI Node SDK: Structured output requirements. We compared strict schema requirements for the Responses API with JSON-mode limitations, nullable required fields, and refusal or incomplete-response handling. We kept appointment confirmation outside model extraction. These are documented feature and workflow reviews, not hands-on vendor tests: we did not upload private data, benchmark a service, listen to generated speech, or obtain deployment approval. Names, examples and diagrams are conceptual. Before production use, recheck official availability, pricing, region and privacy terms, then assign any legal, accessibility or safety judgment to an appropriately authorized human reviewer.
Frequently Asked Questions
No. Schema adherence constrains format; only the library’s authorized scheduling system and staff can confirm a time.
Use a required field with a nullable type and output null when no time is known.
It restricts objects to declared properties in the supported strict JSON schema subset.
No. Handle refusals, incomplete responses, invalid configuration and other errors separately.
No. Use the appropriate authorized tools or application actions to carry out a booking, with confirmation and auditing.