An engineer handed "book 30 minutes with Sarah tomorrow afternoon" produces a correct calendar entry in what feels like one step. It isn't one step. It's five distinct guarantees, established simultaneously because a single semantic model of the task produces all of them at once. Guarantees established together are never named separately — which is why "validate the output" reads as a single operation, and why the phrase is nearly contentless once a model is generating the output instead.

A language model establishes none of the five jointly. Each fails independently while the others hold, and the failures are silent: correct output and output that is wrong at level n are drawn from the same distribution and are indistinguishable by any check operating at level n-1. Separating them is not pedantry; it's the precondition for choosing a mechanism, because the five are not enforceable by the same means, at the same time, or at the same cost.

Take a tool call the harness will execute: create_event(title, start, end, attendees[], calendar_id).

L1 — Syntactic well-formedness. The response parses. Failure modes are mechanical: markdown fences around the payload, trailing commas, unescaped quotes, truncation when the completion hits max_tokens mid-object. Cheap to detect, and the only level where detection is trivially complete.

L2 — Schema conformance. Required fields present, types correct, enums respected, arity and nesting as specified, format satisfied. start is an RFC 3339 timestamp rather than the string "tomorrow afternoon"; attendees is an array rather than a scalar. L1 passing implies nothing here — {"start": "tomorrow afternoon"} is impeccable JSON.

L3 — Cross-field invariants. Constraints over combinations of fields: end > start; duration ≤ 8h; conditional requiredness (if recurrence is present, recurrence_end is mandatory); discriminated-union consistency (the field set must match the declared type). Every field can be individually valid while the object is incoherent — 15:00 and 14:30 are both well-formed timestamps, and the meeting ends before it begins. Field-wise validation is structurally blind to this class, since the defect exists only in the relation between materialized values.

L4 — Referential integrity. The identifiers resolve. calendar_id names a calendar that exists and that this principal is authorized to write to; attendee addresses resolve to real directory entries. This is not a property of the payload — it's a property of the world, established by I/O against a source of truth. Worth stating explicitly because it's the level most often skipped: the model naming a resource is not authorization to touch it, and an agent that treats emitted identifiers as authorized has an access-control bug, not a validation gap.

L5 — Semantic correctness. The event is the one that was intended. 15:00 versus 03:00 across a timezone boundary; the correct Sarah out of two directory matches. L1–L4 all pass. The output is well-formed, conformant, internally consistent, referentially sound, and wrong.

The load-bearing property is that L5 is independent of L1–L4. Form and reference are verifiable by inspection and lookup; truth is not a function of either. Any pipeline reporting "validation passed" while only exercising L1–L2 is reporting on the two cheapest levels and asserting nothing about the one that determines whether the action should fire.

Enforcement: which mechanism reaches which level

Grammar-constrained decoding covers L1 and a proper subset of L2. The mechanism masks the logit distribution at each decode step against an automaton compiled from the schema, so tokens that would violate the grammar are unsamplable. This is prevention, not detection — malformed output is unrepresentable rather than caught downstream.

Its ceiling follows from what it is. The mask is evaluated per token against the prefix produced so far, so it reaches constraints expressible as a regular or context-free property of the token stream: presence, type, enum membership, structure, regex-expressible format. It does not reach constraints requiring comparison of two materialized values (end > start), counting (minItems, maxItems), or global uniqueness (uniqueItems) — these need state the automaton doesn't carry, and in the comparison case both operands don't exist until generation has already moved past the decision point. Engine coverage of JSON Schema also varies (Outlines, XGrammar, llguidance, and provider-native structured outputs compile different feature subsets), so "structured outputs is on" is not equivalent to "my schema is enforced." Verify which keywords your engine actually compiles.

One cost worth budgeting: constraining generation from the first token removes the model's latitude to reason in prose before committing to a structure, which measurably degrades content quality on reasoning-heavy tasks. The standard mitigation is two-pass — unconstrained reasoning, then a separate constrained extraction over that output. You buy L1/L2 on the second pass without taxing the reasoning on the first.

L2's remainder and all of L3 are post-generation assertions. Parse, then evaluate the bounds, arity, uniqueness, and cross-field predicates in code. Detection only; on failure you either coerce deterministically (strip fences, normalize a timezone) or re-generate with the validation error fed back. Cap the regenerate loop at two or three attempts and fail closed — an unbounded repair loop is a latency and cost incident, and persistent failure past the cap usually indicates a schema/prompt mismatch or missing knowledge that further attempts won't resolve.

L4 is I/O. A resolution and authorization check against the source of truth, in the harness, before execution. No amount of payload inspection substitutes for it.

L5 splits on whether truth is computable, and classifying the output on this axis is the first decision to make, not the last. If the output is executable (a query you can run, code you can test), reference-exact (a known correct value), or property-checkable (the result must be a permutation of the input; totals must reconcile), a deterministic check settles it exactly and dominates any model-based judge on both cost and reliability. If correctness is a predicate over meaning — was this summary faithful, was this the intended time — no such check exists, and you are on judgment: a human, or a model-as-judge with its own error rate and bias profile. Do not route a computable case to a judge, and do not let a schema pass stand in for a semantic one.

What this determines

Two questions decide the pipeline for a given output. First, what is the truth class — computable or judgment-only — since that determines whether L5 is verifiable at all and what the error budget has to absorb. Second, which levels does the consumption pattern actually require: an intermediate artifact the model will re-read may need only L1, since a malformed scratchpad self-corrects on the next turn; an output rendered to a user needs L1–L3 with the user as the L5 check; an output the harness will execute needs L1–L4 established before it fires, plus an explicit L5 posture — a deterministic verifier where truth is computable, and a confirmation or draft-commit step where it isn't.

The general statement: a human establishes five guarantees in one act because one semantic model produces all five. Replace the human and they decompose into five separate obligations, enforced by different mechanisms at different points in the pipeline — two preventable at generation, two checkable after, one frequently not checkable at all.