ChatGPT JSON Schema: test the condition that changes what is required

In this original equipment-request example, every request has a mode: pickup or delivery. Delivery requires a nonempty address. Pickup may omit it. Unknown properties are rejected in this deliberately closed input contract.

Make the rules inspectable

The following authored draft uses JSON Schema 2020-12:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "mode": { "enum": ["pickup", "delivery"] },
    "address": { "type": "string", "minLength": 1 }
  },
  "required": ["mode"],
  "additionalProperties": false,
  "if": {
    "properties": { "mode": { "const": "delivery" } },
    "required": ["mode"]
  },
  "then": { "required": ["address"] }
}

The top-level required rule rejects a missing mode. The if condition identifies delivery; then adds the address requirement. Pickup still follows the base rules, so an address supplied with pickup must be a nonempty string. This contract does not forbid pickup addresses. Change that rule explicitly if your intake process needs a prohibition.

The official conditional validation reference, checked October 24, 2026, explains how if and then apply subschemas and why property presence matters.

Challenge each branch

Whitespace-only text is nonempty under minLength. This small schema does not verify a deliverable address, trim a string or look up a location. Those are separate rules and operations. A validator's success means the instance satisfies the implemented schema, not that equipment can reach the address.

Copy a schema drafting prompt

Draft a JSON Schema 2020-12 input contract.
Business fields and exact rules: [PASTE]
Conditional requirements: [PASTE]
Unknown-property policy: [ENTER]
Actual validator/version and supported dialect: [ENTER OR UNKNOWN]

Return the schema, an explanation tied to each rule, and positive and
negative JSON instances. Test every conditional branch, absent selector,
unknown selector, wrong type, empty value and undeclared property.
Separate business decisions from syntax. Do not invent defaults,
normalization, format enforcement or successful validator execution.
Flag any rule that the supplied validator configuration may not enforce.

OpenAI's prompting guidance supports supplying those constraints. Keep the actual validation output beside the proposed fixture expectations when running your project's validator.

Agree the contract before enforcing it

Confirm that rejecting extra properties is intentional; otherwise an added client field can become a breaking input change. Check validator dialect support and run the complete fixtures through the configured implementation. For OpenAPI documentation rather than standalone input design, the API schema explanation guide handles omitted and null fields separately.

Ask the intake owner to review pickup with an address and delivery with whitespace. Those cases expose policy gaps that a syntactically valid schema cannot settle.