DATA CONTRACTS THAT STICK: OWNERSHIP, FRESHNESS, AND BREAKING-CHANGE DISCIPLINE
How to implement data contracts enterprises actually keep: owners, SLAs, schema evolution, and tests in CI - not wiki pages nobody reads.
A data contract is an explicit agreement between producers and consumers: schema, semantics, freshness, and what happens on break. Contracts stick when they live in code with owners and CI checks - not in a Confluence page last edited during a reorg.
Minimum viable contract
- →Owner (team + pager path)
- →Schema with compatibility rules (backward/forward)
- →Freshness and completeness SLOs
- →Consumer list and intended grain/semantics
- →Change process: how breaks are proposed, reviewed, versioned
Put tests where deploys happen
Contract tests in the producer pipeline catch breaks before dashboards lie. Consumer contract tests catch silent semantic drift. Pair with a catalog so discovery and ownership stay linked - see /products/data-platform and /solutions/data.
Evolution without chaos
Prefer additive changes. Deprecate with dates. Dual-write or dual-read during migrations. Never 'sneak' a semantic change under the same field name - that is how month-end becomes archaeology.
If nobody owns freshness, you don't have a contract - you have a hope.