Data Contracts as Producer Obligations
Why moving the schema definition to the producer changes the economics of data quality, what a contract must contain beyond field types, and the organisational conditions under which contracts actually work.
The default arrangement in most data platforms is that a producing service writes whatever it writes, and a data team downstream discovers changes by having something break. The producer has no visibility into who consumes their data and no incentive to be careful with it; the consumer has all the pain and none of the control. Data contracts invert this by making the interface explicit and making the producer responsible for honouring it.
What is in a contract
A contract is more than a schema. It specifies:
Structure: fields, types, nullability, enumerations, and their stable identifiers.
Semantics: what each field means, including units, timezone, and the precise definition of anything computed. This is the part most often omitted and most often the source of misuse.
Guarantees: delivery frequency, freshness SLA, expected volume range, uniqueness and referential properties the producer commits to.
Evolution policy: what counts as a breaking change, how versions are numbered, and how long an old version is supported.
Ownership: who is accountable, and how to reach them.
The evolution policy is the part that carries most of the value. Adding an optional field is safe; removing a field, narrowing a type, changing units, or changing the meaning of an existing value are all breaking, and the last one is the one that slips through because it does not change the schema at all.
Enforcement
A contract that is a document is a wish. Enforcement requires that it be machine-readable and checked in the producer's own delivery pipeline, so a change violating the contract fails the producer's build rather than the consumer's job at 3am.
That is the actual shift: quality checks move from the consumer, who can only detect problems, to the producer, who can prevent them. Serialisation formats with schema registries provide a mechanical version of this by rejecting incompatible writes at the boundary.
When it breaks
Contracts need organisational backing. A data team cannot impose a contract on a product team that does not report to them and has no incentive to comply. Contracts work where there is either a shared platform requiring them or leadership treating data as a product with owners. Without that, they become documentation that drifts.
Semantic changes evade schema enforcement. Changing revenue from gross to net keeps the type and breaks every consumer. No registry catches it. Only distribution monitoring on the consumer side, or a genuine review process on the producer side, will.
Over-specification makes producers hostile. A contract demanding guarantees the producer cannot meet, such as strict ordering from a system that does not provide it, gets ignored or gamed. Contracts should encode what is genuinely required by consumers and genuinely achievable by the producer, and negotiating that is the work.
Versioning has a real cost. Supporting two versions of a stream means dual writes, twice the storage, and a migration nobody prioritises. Contracts without a deprecation process accumulate versions until the producer is maintaining five, at which point the discipline is abandoned.
Contracts do not make the data correct. They make it structurally predictable and on time. A field that is always present, correctly typed, and populated with the wrong value satisfies every contract. Quality checks on values remain necessary, and treating a contract as a substitute for them is a category error.
12 flashcards for this concept
Click a card to reveal the answer.