Producer-Enforced Contract

Data contracts are frequently introduced consumer-side: downstream teams declare what they need, and the declaration is checked when the data arrives. That detects a breach after it has happened, in a pipeline owned by someone who cannot fix the cause.

A data contract is only a contract if the producer's build fails when it is broken.

Why it matters

The failure mode without enforcement is not that contracts are absent — it is that they exist, are believed to provide protection, and provide none. Teams reason about the platform as though changes are governed while the governance operates only after the fact.

Implementation patterns

• Enforcement in the producing team's pipeline, so the breaking change is blocked at source.
• Compatibility rules: additive changes allowed, removals and type changes requiring a version.
• Semantics documented alongside the schema — what each field means, its units, when it is populated, and what it does not mean. The negative statements are the valuable ones, because a semantic change with an identical shape passes every automated check while consumer behaviour quietly diverges.
• Quality expectations, not only structure: null rates, value ranges, uniqueness, freshness. A field that is present and always null satisfies a structural contract and breaks its consumers.
• A named owner on the producing side with an SLO consumers can rely on.
• Consumer registration, so a producer can assess the impact of a change — without it, a producer cannot change anything safely and therefore does not, which is the coupling the contract was meant to remove.
• Contract only the interfaces others depend on. Contracting exploratory and one-off data makes the platform rigid and the process bypassed — the same distinction as a public API versus an internal function.

Industry example

Multi-product SaaS organisations such as Freshworks have producing teams who reasonably regard their tables as an implementation detail, and consuming teams who have built on them. The technical mechanism is straightforward; the difficulty is that enforcement makes the producing team accountable for something they previously were not, and that is the real work.

The platform's job is to make compliance cheap — generating the contract from the schema, providing the tests, and absorbing the migration cost when a contract must legitimately change.

Failure scenarios

• Consumer-side declaration only, detecting breaches after they ship.
• Structure without quality expectations, so an always-null field passes.
• Semantics undocumented, leaving the class of change nothing catches.
• No consumer registry, so producers freeze rather than risk a break.
• Everything contracted, making the platform rigid and the process bypassed.

Trade-offs

Enforcement slows the producing team, and a contract that is expensive to change discourages legitimate evolution — which produces schemas that accumulate rather than improve.

The mitigation is a supported change path: a versioned contract, a notice period, migration tooling, and the platform absorbing the consumer-side work. Without that path, enforcement produces resentment and a frozen schema, which is a different failure from the one it was preventing.

Interview question

"Your data contracts are defined and a producer's schema change broke three pipelines last week. Explain how that was possible, and tell me what you would change — including what the producing team will object to."