01 / STRUCTURED DATADistinguish a snapshot from a change event
Write down whether a record represents current state or an operation that changes state. A quantity of seven means little until the consumer knows whether it is a total, an increment, or a correction. Keep event identity separate from entity identity, and define how repeated delivery affects the stored result.
02 / STRUCTURED DATADocument units, nulls, and field ownership
Document the meaning of each field along with its type. An absent value, a null, and a zero should not become interchangeable through convenience defaults. Include explicit units where they matter, and test values at the accepted boundaries. A readable fixture can reveal ambiguity that a syntactically valid schema leaves unresolved.
03 / STRUCTURED DATAKeep transformations and provenance traceable
Keep the source reference and transformation history needed to explain a derived record. When combining observations, retain the relationship to the inputs where your application needs it. A normalized category can coexist with the source’s original category. Preserving that distinction makes review and later correction easier than overwriting the evidence.
Write three records that expose the contract
Create an ordinary record, a record with an unknown value, and a correction to an earlier record. Ask another developer to interpret each using only your documentation. A disagreement about units, deletion, or order identifies a contract gap worth fixing before the first production consumer. Keep these examples as permanent fixtures and run them whenever the schema or normalization code changes.