Contracts & Schema Evolution

An explicit, owned, enforced agreement between the team that produces data and the teams that depend on it — covering names, types, nullability, meaning, freshness and how it may change.

Schemas change constantly. Adding, removing, renaming and retyping a field are four different risks with four different blast radii — and only one of them is routinely safe.

The producer ships first: data written under the new schema must still be readable, and still correct, for consumers that have not upgraded. State it as writer-and-reader, because the word itself is used in opposite directions by different communities.

The consumer ships first: data written under the old schema must still be readable, and still correctly interpreted, by code running the new one. In analytics this is not an edge case — every query over history is this question.

A shared, versioned store of schemas with a compatibility gate in front of it. It makes structural evolution mechanical — and it has nothing to say about meaning, ownership or the consumers reading your data by some other path.

A numeric field starts arriving as a string. Some consumers error; the dangerous ones cast, get null, keep every row, and report zero — with completeness, uniqueness and freshness all green.

The schema is identical, every type checks, every test passes, and the number now means something else. `revenue` went from gross to net. No tool will ever detect this — only documented semantics, an owner and a changelog will.

Making a field nullable is a breaking change for everyone who assumed it was not. A default hides missing data behind a plausible value. And "unknown", "not applicable" and "the pipeline dropped it" are three different facts stored identically.

Where the check actually runs — producer CI, the ingestion boundary, the entry to transformation — and the trade every enforcement point makes: a silent wrong number becomes a loud failure, which is correct and will still page someone.