Producer Obligation
What a data contract binds the producing team to do, and — crucially — what happens in their pipeline when they are about to break it.
A contract has two sides, and the consumer side is the easy one. The producer's obligations are what make it meaningful: hold the schema stable within a compatibility mode, preserve stated semantics, meet a freshness and completeness guarantee, and give notice before a breaking change.
The mechanism that makes those obligations real is enforcement in the producer's own build. Schema, enum and uniqueness checks run in their CI and block the merge. Freshness and completeness are monitored continuously with alerts routed to them.
Checked only downstream, a contract reports the breakage after it has shipped, which is documentation with a version number.
The semantic obligation is the hardest to enforce and causes the most damage. A
field renamed is caught by any schema check; a field whose meaning changes —
amount starting to include tax, created_at quietly becoming ingestion time —
passes every type check and silently corrupts every downstream calculation.
Partial defences exist: distribution monitoring catches a step change in a
numeric field, and requiring semantic notes in the contract at least makes the
change reviewable. Neither is complete, which is why the cultural half — producers
understanding they have consumers — is not optional.