A sanitation department's missed-pickup triage returns a JSON object that its dispatch system parses with a strict reader. The model reliably produces the six agreed fields but sometimes adds helpful extras such as 'confidence_note' or 'suggested_crew', and the reader throws on unrecognized keys. Which schema change addresses this?

An output schema is a contract between a producer and a consumer, and a contract that enumerates fields without saying whether the list is exhaustive has left its most important clause implicit. The dispatch system's strict reader assumes closure; the schema never stated it, and the model has been filling that silence with helpful extras.

Declaring the object closed to additional properties, and stating in the prompt that only the six named fields may appear, makes exhaustiveness an explicit term both sides can see. The model reads a field list that is final rather than illustrative, and any drift becomes a validation failure at the boundary instead of a silent change in payload shape.

Relaxing the reader to ignore unknown keys hides the drift rather than preventing it, leaving the department blind to a model emitting fields nobody reviewed; shortening the field names has no bearing on whether the model believes it may add fields; and adopting the invented keys into the schema legitimizes unspecified output while inviting the next round of improvisation.

Exam caveat: closure is only as real as whatever validates the output, since a sentence in the prompt is guidance and the boundary still needs a validator that actually rejects extra keys. Operational check: replay a missed-pickup case that previously produced confidence_note, confirm the closed schema rejects or suppresses it, and assert the dispatch reader parses the six agreed fields without throwing.