In OpenAI strict json_schema mode, what schema rules apply and how do you mark a field optional?

## Why there is a dialect at all Strict Structured Outputs works by compiling your schema into a formal grammar and masking the sampler to tokens that can still complete a valid document. A grammar compiler cannot handle arbitrary JSON Schema — validation keywords that require looking at a finished value (arbitrary cross-field conditionals, unconstrained open objects) do not translate into a decision the decoder can make one token at a time. So `strict: true` defines a subset, and anything outside it is rejected when you submit the request. That rejection is a feature. You learn about an unsupported schema in development, as a 400, rather than in production as a slow quality drift. ## Rule 1 — closed objects Every object in the schema, root and nested alike, must carry `"additionalProperties": false`. Without it the grammar would have to admit arbitrary keys, which defeats the purpose. In practice this is the most common cause of a rejected schema, because most hand-written and most tool-generated schemas leave `additionalProperties` unset (which in plain JSON Schema means "anything goes"). ## Rule 2 — everything is required Every key listed under `properties` must also appear in the `required` array. A schema with five properties and three required entries is rejected. Newcomers read this as "strict mode cannot express optional fields," which is not quite right — it cannot express *absent* fields. ## Expressing optionality: the nullable union The supported pattern is to keep the key required and widen its type: - `"middle_name": {"type": ["string", "null"]}` Now the model must emit `middle_name`, but `null` is an allowed value. Your application then treats `null` exactly as it would have treated an absent key. If you generate schemas from typed models — Pydantic in Python, Zod in TypeScript — the SDK helpers do this translation for you when a field is declared optional, which is one strong argument for generating schemas rather than writing them by hand. A subtlety worth knowing: because the field is always present, the model spends tokens emitting it. On a wide schema with many rarely-populated fields, that is real cost and real latency, and it is a reason to keep extraction schemas narrow. ## Other shape rules - **Root must be an object.** You cannot make the root a bare array or a top-level `anyOf`; wrap it, e.g. `{"items": [...]}`. - **`anyOf` is allowed for non-root positions**, which is how you model a discriminated union of result shapes. - **Recursion is supported through `$defs` and `$ref`**, including a reference to the root, so tree-shaped outputs like an expression AST or a nested outline are expressible. - **Enums are supported** and are usually a better classification tool than free-form strings, because the grammar makes an out-of-vocabulary label impossible rather than merely unlikely. - **Only a subset of type-specific validation keywords is honoured**, and the supported set has expanded over time. Treat any keyword beyond structure — patterns, numeric bounds, array cardinality — as something to confirm against current documentation and, regardless, to re-check in your own code. - **Hard limits exist** on total properties, nesting depth and total schema size. A schema that models an entire domain will hit them; one that models a single call's output rarely does. ## Design consequences The dialect pushes you toward small, purpose-built schemas rather than reusing your internal domain model. That is generally the right instinct anyway: the model should be asked for the fields the call needs, not for every field a database row happens to have. Property order matters more than in ordinary JSON Schema. Because decoding is left-to-right, fields are produced in the order the schema declares them, so a field intended to hold the model's working — an `analysis` or `evidence` string — must be declared *before* the conclusion it supports, or the conclusion is generated first and the analysis becomes post-hoc narration. Finally, the restricted dialect means the schema is not your whole validator. Business rules — a total that must equal the sum of the line items, a date that must be in the past, an identifier that must exist in your database — live in application code no matter how expressive the schema subset becomes. ## Interview framing Name the two structural rules, give the nullable-union answer for optionality, and add one consequence — usually that you should generate the schema from a typed model rather than hand-maintain it, since the helper applies both rules automatically.