Structured Generation in Apps

Structured generation in apps is the end-to-end pattern of schema-driven LLM output — define a schema (L143), constrain the provider's generation to it, validate the result at your boundary, and consume a typed object — so the stochastic model feeds deterministic code through a contract.

The one-sentence interview answer: "Structured generation is a pipeline: I define the schema — the contract (L143); the provider constrains generation to it, so malformed output is impossible; I validate at my boundary, because the guarantee is shape, not truth (L141); and the validated object feeds typed code — forms, tables, tools — with no parser in sight. The schema is the interface between the stochastic model and the deterministic app."

Think of structured generation as a factory with a mould — the schema is the mould, the model pours the content, and the QC inspector (validation) checks every piece before it ships.

   the schema (mould, L143)         the model (pours)       your app (the product)
   ┌──────────────────────┐        ┌──────────────┐        ┌──────────────────────┐
   │ { name: string       │        │  "Acme Corp  │        │  typed object:       │
   │   total: number      │  ───▶  │   1249.99    │  ───▶  │  { name: "Acme Corp",│
   │   dueDate: string }  │        │   2026-09-01 │        │    total: 1249.99,   │
   └──────────────────────┘        └──────────────┘        │    dueDate: … }      │
       the contract                constrained (L143)      validated, no parser

The mental model is three stops: define the mould (schema), pour (constrained generation), inspect (validation). Skip the inspection and the factory ships defects; skip the mould and it ships whatever.

   your app wants a typed record from text
        │
        ▼
   ┌──────────────────────────────────────────────┐
   │ 1 · DEFINE the schema (the contract, L143)   │
   │     Zod: { name, total, dueDate }            │
   └──────────────────┬───────────────────────────┘
                      ▼
   ┌──────────────────────────────────────────────┐
   │ 2 · CONSTRAIN generation (L143)              │
   │     generateObject({ schema }) → the provider│
   │     must emit schema-valid JSON              │
   └──────────────────┬───────────────────────────┘
                      ▼
   ┌──────────────────────────────────────────────┐
   │ 3 · VALIDATE at your boundary (L143, L168)   │
   │     schema.parse(result) — shape, verified   │
   │     (the provider guarantees shape, NOT truth│
   │      — values are still your job, L141)      │
   └──────────────────┬───────────────────────────┘
                      ▼
   ┌──────────────────────────────────────────────┐
   │ 4 · CONSUME the typed object                 │
   │     a table, a form, a tool call, a DB row   │
   └──────────────────────────────────────────────┘

The pipeline is the pattern: define → constrain → validate → consume. Every step has a lesson (L143 for the first two, L168 for the third, L165/L158 for the fourth).

• Define the schema (L143). The schema is the contract: types, enums, required fields. It's also a steering tool — an enum tells the model the allowed values; a required field forces completeness. The schema is an instruction wearing a type.
• Constrain generation. generateObject/streamObject (L160) sends the schema to the provider, which constrains token generation to schema-valid output (L143's mechanism). Malformed JSON is impossible; a clean error is possible.
• Validate at your boundary. The provider guarantees shape against the schema you sent; your code validates the received payload — SDK version, proxy, or model drift can differ (L341). Validation is cheap and non-negotiable.
• Consume the typed object. The validated object feeds deterministic code: a table, a form, a tool call (L144), a database row (L226). No parser, no regex, no "maybe it's a string".

• Extraction pipelines. Invoices, receipts, emails → typed records: generateObject with a Zod schema, validated, into the DB (L226). The parser is gone.
• Typed forms. A document → a form that fills itself: streamObject renders the typed fields as they form (L162), validated live (L143).
• Tool-call arguments (L164). The schema IS the tool's parameter contract — the model's args are schema-valid by construction, so your execute never guesses (L144).
• Classification at scale. An enum schema prevents invented labels — the allowed set is in the contract, not the prompt (L142).
• Agent data flow (L200). Every agent step's output is a typed record (schema-validated), so the loop's data is type-safe even though the model is stochastic.

The through-line: structured generation is the seam that makes LLM output composable — a typed contract in, a typed object out, and the deterministic app never touches a raw string.

Say it in four moves:

1. The frame. "Structured generation is a pipeline: define the schema, constrain generation to it, validate at my boundary, and consume a typed object (L143)."
2. The mechanism. "The provider constrains token generation to schema-valid output — malformed JSON is impossible (L143). generateObject/streamObject (L160) wrap this."
3. The validation. "The guarantee is shape, not truth (L141). I validate the received payload — the provider can differ from the SDK — and the values are still my job."
4. The payoff. "The typed object feeds deterministic code — tables, forms, tool calls, DB rows — no parser anywhere. The schema is the interface between the stochastic model and the deterministic app."

• The schema is the app's interface, not the provider's (L143). The same schema should work across providers (L155): OpenAI's response_format, Anthropic's input_schema, Gemini's responseSchema all express it. Define once, validate once, consume everywhere.
• The schema steers semantics (L143). Enums, required fields, and descriptions guide the model — the schema is a prompt wearing a type. A well-designed schema produces better content, not just valid shape.
• Validation is the drift detector (L341). Model upgrades can change output subtly; your boundary validation catches it. The schema is both the contract and the regression test.
• Structured output composes with streaming (L145, L161). streamObject emits object parts — the typed form fills as the model generates, validated live (L162). The streaming UI and the contract are one pipeline.
• "Valid but wrong" is the remaining surface (L141). The senior design adds content checks — plausibility, grounding, or a human gate for consequential values (L208, L324). The mould fixes the form; the architecture fixes the facts.

• Parsing content with regex. The demo's tell — one model update or stray emoji from a broken parser (L143).
• Trusting the provider's guarantee without validating. The guarantee is against the schema you sent; the received payload can differ (SDK, proxy, model drift, L341).
• Loose schemas. type: 'object' with no properties — no shape to constrain, no contract to build on.
• No content verification. A schema-valid hallucinated amount (L141) — the mould passed, the facts didn't.
• Schema as an afterthought. Changing the schema = breaking the contract (and the cache, L171). It's versioned, like an API.
• Ignoring the error path. The provider's clean error (couldn't produce valid output) unhandled (L168) — a 500 instead of a re-ask.

• Use generateObject/streamObject with a Zod schema (L160) — the schema is the contract and the type source.
• Validate at the boundary, always (L143) — schema.parse(result), never trust the string.
• Design the schema to steer (L143) — enums, required fields, descriptions.
• Add content verification for consequential values (L141, L208) — shape + truth.
• Version the schema — it's a contract and a cache key (L171, L341).
• Handle the error path (L168): re-ask once, then degrade — never a raw 500.

Q: What is structured generation, end to end?

A: A pipeline. Define a schema — the contract (L143). The provider constrains generation to it, so malformed JSON is impossible. I validate at my boundary — the guarantee is shape, not truth (L141). Then I consume a typed object — tables, forms, tool calls, DB rows — with no parser anywhere.

Q: Why validate if the provider guarantees the shape?

A: Because the guarantee is against the schema I sent, and the received payload can differ — the SDK, a proxy, or a model upgrade (L341). Validation is cheap, and it's also the drift detector: the schema doubles as the regression test for model behavior changes.

Q: How does this relate to tool calling (L144)?

A: The tool's parameter schema IS structured generation pointed outward. The model's args are schema-valid by construction (L143), so my execute receives a typed object, never raw args to guess at. Tool calling and structured output are the same contract in two directions.

Q: How do you handle a schema-valid but wrong value?

A: The mould fixes the shape, not the facts (L141). For consequential values I add content verification — grounding (L191), a plausibility check, or a human gate (L208, L324). Structured generation removes the parsing failure class; the content failure class is still the architecture's job.

• How does streamObject differ from generateObject (L145, L161)?
• How do you keep the schema stable across model upgrades (L341)?
• How does the schema steer the model's semantics (L143)?
• How does structured generation compose with RAG (L191)?
• When is a plain-text answer right instead of a schema (L142)?

The senior read: the table is the decision rule (L143, L157) — if a parser touches the output, structured generation is the only production answer.

// Structured generation end to end: schema → constrained → validated → typed.
import { generateObject, streamObject } from 'ai';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';

// 1 · THE SCHEMA — the contract, and the type source (L143).
const InvoiceSchema = z.object({
  vendor:   z.string().describe('The seller name.'),
  total:    z.number().positive().describe('The invoice total, as a number.'),
  currency: z.enum(['USD', 'EUR', 'GBP']),
  dueDate:  z.string().describe('ISO date, or null if not present.').nullable(),
});
type Invoice = z.infer<typeof InvoiceSchema>;   // the type, from the schema

// 2 · CONSTRAIN — the provider must emit schema-valid JSON (L143).
const { object } = await generateObject({
  model: openai('gpt-4o-mini'),               // the tier, by L157
  schema: InvoiceSchema,
  prompt: 'Extract the invoice fields from this text:\n' + text,
  // temperature: 0 — a fact question (L139)
});

// 3 · VALIDATE — the boundary check (cheap, always on).
const invoice: Invoice = InvoiceSchema.parse(object);

// 4 · CONSUME — a typed record into deterministic code.
await db.invoices.create({ data: invoice });   // no parser, no regex, no guess

What the reader must SEE — the pipeline in code:

  z.object({…})       → the contract + the type (L143)
  generateObject      → constrained generation (L160 wraps L143)
  InvoiceSchema.parse → boundary validation, always
  db.create(invoice)  → typed consumption, no parser

  Shape guaranteed · truth verified · app never sees a string.

• streamObject preserves the streaming feel (L145, L161) — the typed fields render as they form; the latency is the provider's, not the pipeline's.
• Complex schemas add generation latency (L143, L151) — the constrained sampling costs per token; keep schemas flat.
• Validation is microseconds (L151) — schema.parse is nothing against the model call; never skip it for speed.
• The schema is a cache input (L171) — a stable schema + stable prompt keeps the request cache-friendly; changing it invalidates the cache and the eval contract (L341).

• Structured generation = a pipeline: define → constrain → validate → consume (L143).
• Define the schema — the contract + the type source.
• Constrain — generateObject/streamObject (L160) wraps L143's mechanism.
• Validate at the boundary — shape guaranteed, truth not (L141); always schema.parse.
• Consume the typed object — no parser anywhere (L158, L165).
• The schema is the interface between the stochastic model and the deterministic app.

STRUCTURED GENERATION = schema → constrained → validated → typed

  1 DEFINE   the schema (L143)
             types · enums · required · descriptions
             = the contract + the type source
  2 CONSTRAIN  generateObject / streamObject (L160)
             the provider must emit schema-valid JSON
             malformed is impossible; clean error possible (L168)
  3 VALIDATE  at your boundary, always
             schema.parse(result) — shape, verified
             (shape ≠ truth — values are your job, L141)
  4 CONSUME   typed object → table / form / tool / DB row
             no parser, no regex, no guess

RULES
  the schema steers semantics (enums, required) — L143
  validate received payload, never trust the string (L341)
  version the schema — it's a contract and a cache key (L171)
  add content checks for consequential values (L208)

INTERVIEW, 4 MOVES
  1 frame    "define → constrain → validate → consume"
  2 mechanism "constrained generation (L143), wrapped by L160"
  3 validation "shape yes, truth no (L141) — parse at the boundary"
  4 payoff   "typed object in, no parser — the app never sees a string"

You now hold the seam that makes LLM output composable: define → constrain → validate → consume, with the schema as the contract between the stochastic model and the deterministic app. It's the same seam that tool calling (L144) points outward, that agents (L200) run their data through, and that every extraction pipeline in the RAG module (L174+) builds on.

Next: the other direction of the contract — tool calling in applications (L164), where the model doesn't just return data, it asks your app to act.