Define the downstream decision first
Suppose an application extracts appointment details from “Please book 15 October 2026; I will send the time later.” This is an invented input. A scheduling function cannot create an event safely because time and timezone are absent. The desired extraction result is therefore not a completed appointment. It is a structured representation of known and missing information. Before selecting a prompt or provider feature, decide how your application will distinguish an incomplete request from one that can be scheduled. Without that rule, a tidy object may hide a dangerous guess.
Separate four validation layers
Parsing establishes whether the bytes represent JSON. Schema validation establishes whether the object has permitted keys and values of the expected types. Domain validation establishes whether a date or other value makes sense for your application. Evidence validation establishes whether each value was actually supplied. These checks are not interchangeable. The string “2026-02-30” has a date-like shape but is not a real calendar date. A valid timezone string can still be invented. An extra explanatory paragraph outside the object may break a parser even if its explanation is correct.
Write a contract with an explicit unknown state
For this example require date, time, timezone and missing_fields. Use null for an absent scalar and an array of field names for missing_fields. Require an ISO calendar date when a full date is supplied. Do not infer a timezone from a name, an IP address or an assumed location. Document whether an empty string is permitted; in this exercise it is not a substitute for null. The authored reference below has a known date and two missing scalars. It is intentionally incomplete, and a scheduler should stop for clarification.
Use provider constraints without overclaiming
Where an API supports schema-constrained outputs, use its documented mechanism and check which schema features it accepts. A natural-language instruction to “always return JSON” is not the same mechanism. Provider features do not replace handling a refusal, interrupted response, unavailable model or application-level rejection. This tutorial does not supply a model-specific API recipe because parameter names and feature support can change. Follow the provider's current documentation and keep the application's own checks independent of the model call.
Run the failure exercise
Begin with the reference object. Delete missing_fields and observe whether your schema check rejects it. Change null to the string “unknown” and verify the expected type policy. Add a time of “25:90” to show why format and domain checks matter. Then add a plausible timezone that was not in the input: the schema might accept it, but evidence review must reject it. The local Prompt Checker linked below includes a small, deterministic appointment JSON exercise. It is not a general JSON Schema validator and it does not call a language model.
Gate the external action
Do not create an event merely because parsing succeeds. Require all scheduling fields, a real date and time, and explicit user confirmation of the interpreted timezone. Preserve the raw input alongside the validated extraction when your privacy policy allows that storage. If a request is incomplete, ask a focused clarification question rather than repeatedly prompting the model to “fix” missing evidence. Record invalid cases in your evaluation set, with the expected failure reason. This makes improvements measurable without mistaking well-formatted fiction for reliable automation.
Worked example
INPUT
Please book 15 October 2026; I will send the time later.
AUTHORED REFERENCE JSON
{"date":"2026-10-15","time":null,"timezone":null,"missing_fields":["time","timezone"]}
EXPECTED WORKFLOW
Parse → check contract → check calendar values → check evidence → ask for time and timezone. Do not schedule yet.How to check the result
Treat parsing, contract validation, calendar validity and evidence as separate checks. A correct incomplete object should be accepted as extraction data but must not trigger scheduling.