Event schema governance
Missing and cleared fields are different operations
Optional data needs an explicit interpretation. An omitted field, a null value and an empty string should not accidentally trigger the same update.
In this article
Work through a concrete edit
A customer removes an optional delivery instruction. One producer sends null. Another omits the field because its serializer drops empty values. A consumer treats omission as no change, so the old instruction remains visible.
The message passed structural validation. The defect comes from combining a partial-update interpretation with a producer that cannot express clearing the value reliably.
Before reviewing the schema, write the expected outcomes for leaving a value unchanged, replacing it and removing it. These are three distinct intentions even when the chosen encoding uses only two familiar JSON forms.
Inspect the complete encoding path
Check how the producer's language model, serializer and schema represent absence. Then inspect what the consumer receives after deserialisation. Some model layers collapse distinctions before application code can examine them.
{
"unchanged": {},
"cleared": { "deliveryInstruction": null },
"replaced": { "deliveryInstruction": "Use the side entrance" }
}This is an illustrative partial-update convention, not a universal event standard. Under a full snapshot contract, absence could mean something else. The contract must say which model applies.
Test an empty string separately. It may be invalid, equivalent to clearing or an intentionally stored value. Avoid allowing whichever database conversion happens first to decide the policy.
Check older readers and stored history
A new distinction is useful only if existing consumers can preserve it. Review old fixtures and the behaviour of rollback versions. A consumer that previously converted null to an empty string may continue doing so during deployment.
If historical messages did not distinguish missing from cleared, document that limitation. A migration cannot reconstruct the user's original intention from ambiguous data without another source of evidence.
Look at projections and search indexes as well as the main database. A cleared instruction that disappears from one screen but remains in a cached document is still a visible defect.
Require evidence at the business boundary
The review should include a test that sets an instruction, leaves it untouched during another edit and then clears it. Verify the final state through the normal read path.
Repeat the clear event to check duplicate handling, and apply an older update according to the documented ordering policy. This exposes whether a stale event can restore removed text. Approve the change when those outcomes match the contract, not merely when the schema validator accepts all three examples.
Primary sources
JSON Schema: null valuesReferences checked 11 September 2026.