Contract Enforcement Point

Most organisations that suffer contract breakages have contracts. What they lack is enforcement in the right place.

A contract checked at consumption fails in the consumer's pipeline, hours or days after the change, for a change the consumer cannot attribute. A contract checked at production, in the producer's build, fails immediately, at the place the change was made, by the person who made it, with the incompatibility named.

A contract that is not a build gate is documentation, and documentation drifts.

Why the timing gap matters so much

Interactive consumers fail loudly and immediately, so the causal link is obvious. Batch consumers fail at 2 a.m. having skipped a run — and by the time anyone looks, the producer's change is several deploys back and no longer an obvious suspect. The delay is what converts a five-minute fix into an investigation.

Enforcement at the producer removes the gap entirely rather than shortening it.

Implementation patterns

• Schema compatibility checked in producer CI against the registered contract, blocking the merge.
• Full compatibility as the default for shared streams and datasets, since backward compatibility alone still breaks consumers reading older data and you cannot control upgrade order.
• Semantic assertions alongside schema checks, because the most damaging changes leave the type intact and shift the meaning — producing wrong numbers rather than errors, which no schema check catches.
• Additive change only, with field identifiers never reused after removal. Reusing an identifier produces silent data corruption rather than an error.
• A consumer registry, converting deprecation from an unbounded broadcast into a conversation with named teams — and giving the producer a reason to believe a change is safe.
• Deprecation by measured usage rather than by notice period alone.
• A published surface that is easier to use than the base tables. If reading the underlying tables is simpler, consumers will, and every process fix erodes.

Industry example

The recurring enterprise pattern is several teams writing to shared core tables and changing schemas independently. Nobody can state what is always true of a table, adding a constraint breaks a batch job overnight for a team the changer cannot name, and releases have to be sequenced across teams that have no other reason to coordinate.

Moving enforcement into producer CI, plus a registry of consumers, is what converts that from an ongoing coordination tax into a build failure the producer resolves alone.

Failure scenarios

• Enforcement at consumption only, so failures are late, attributed poorly and repeated.
• Compatibility mode too weak for the actual upgrade-order reality.
• Schema-only checks, missing semantic drift.
• Identifier reuse, corrupting data silently.
• Consumers bypassing the published surface, leaving the coupling in place under a contract.
• No registry, so the producer cannot distinguish a safe change from a breaking one.

Trade-offs

Producer-side enforcement shifts cost onto producers, who must now maintain compatibility for consumers they did not ask for and cannot always name. That friction is real and it is the point — it makes the cost of a breaking change visible to the person choosing to make it.

For a dataset with one consumer inside the same team, this is overhead. It becomes valuable precisely when the consumer is someone the producer does not speak to daily, which is the situation a data platform exists to create.

Interview question

"You have data contracts and you still get breakages. Where are you checking them, and what would change if you moved the check?"