A fire-dispatch quality-review pipeline extracts a structured incident record from call transcripts. When the transcript never states the caller's callback number, the model simply leaves the callback_number key out, and downstream code cannot distinguish 'not stated on the call' from 'the extractor failed'. What schema change resolves the ambiguity?

Two very different conditions are being collapsed into one signal: the transcript never stated a callback number, and the extractor did not do its job. A schema that lets a key simply vanish gives both outcomes the same representation, so no consumer of the incident record can tell a clean call from a broken run.

Marking callback_number required with a nullable type forces the model to emit the key on every record and set it to null when the transcript contains no number. Absence becomes a deliberate assertion rather than a gap, every record carries a stable shape, and validation regains meaning, because a record missing the key is now unambiguously a defect worth alerting on.

Making the field optional preserves the exact ambiguity being reported, since a missing key still carries two meanings; defaulting to an empty string invents a value the transcript never supported and can be mistaken downstream for a real blank number; and moving the field into free-text notes abandons structure entirely, forcing every consumer to parse prose to recover a phone number.

Exam caveat: required-and-nullable fixes representation rather than honesty, since a model still under pressure to fill fields can emit a plausible number instead of null, so the prompt must explicitly authorize null for anything not stated. Operational check: run transcripts known to omit the callback number and assert the key is present with a null value on every one.