Structured Outputs made prompts less magical

Structured Outputs moved a common integration problem from prompt superstition into schema work.

Before constrained output, teams asked for JSON, added examples, parsed the answer, and repaired the failures with another prompt. It worked often enough to ship and failed often enough to become infrastructure.

A schema is the contract:

{
  "type": "object",
  "properties": {
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"]
    },
    "summary": {
      "type": "string"
    },
    "requiresHumanReview": {
      "type": "boolean"
    }
  },
  "required": ["priority", "summary", "requiresHumanReview"],
  "additionalProperties": false
}

The schema says what downstream code can rely on. It also forces decisions about fields, enums, review flags, optionality, nulls, and empty arrays.

Valid shape is not valid meaning. Separate schema validity from domain validity, policy validity, evidence support, review routing, and side effects.

Explicit nullability can distinguish an absent source value from an omitted output:

{
  "type": "object",
  "properties": {
    "dueDate": {
      "type": ["string", "null"],
      "description": "ISO date when explicitly present in the source."
    },
    "dueDateEvidence": {
      "type": "string"
    }
  },
  "required": ["dueDate", "dueDateEvidence"],
  "additionalProperties": false
}

Strict tool schemas reduce invented arguments and missing fields, but the application still validates identity, permissions, business rules, rate limits, and side effects.

Once output feeds a workflow, the schema is versioned:

{
  "schema": "ticket_triage_result@3",
  "model": "gpt-4o-2024-08-06",
  "prompt": "ticket_triage@12"
}

Evaluate both shape and meaning. Check JSON, required fields, extra properties, enums, extracted values, uncertainty routing, citations, and allowed tool arguments.

Structured output does not turn a model into a database. It makes the integration boundary explicit.