A schema change in one team's service breaks four downstream data consumers overnight. The contract existed. What failed?

The likely failure: enforcement location

A contract enforced at consumption fails at 2 a.m. in the consumer's pipeline, for a change made days earlier by someone who cannot be identified from the failure. A contract enforced 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.

The other candidates

• Compatibility mode too weak. Backward compatibility alone permits changes that break producers reading older data. Shared streams generally need full compatibility, because you cannot control upgrade order.
• The contract covers schema but not semantics. The field type is unchanged and its meaning shifted — which no schema check catches and which is the more damaging failure because it produces wrong numbers rather than errors.
• No consumer registry. The producer had no way to know who depended on the field, so the change looked safe.
• Consumers reading base tables anyway, bypassing the published surface because it was easier. The contract exists and the coupling is unchanged.

What to change

Move enforcement into the producer's CI. Register consumers so dependency is visible. Add semantic assertions alongside schema checks. And make the published surface easier to use than the base tables — otherwise consumers will keep routing around it, and every process fix will erode.