Data contracts for data leaders: catching bad data before the board does

Most bad data isn’t created by the data team. It’s created upstream (a product team renames a column, an application starts writing nulls, a source system changes the meaning of a status code) and it’s discovered downstream, usually by someone senior asking why a number changed.

Data contracts move that discovery to the moment the change happens.

What a data contract is

A data contract is an agreement between a producer (the team or system that creates a dataset) and its consumers (reports, pipelines, models). It states:

• Schema: columns, types and which fields can’t be null.
• Meaning: what key fields represent, including valid values.
• Quality expectations: freshness, volume, uniqueness, and business rules.
• Ownership: who owns it, and who to contact before changing it.

The important part: a contract is enforced by automated checks. A document nobody reads isn’t a contract.

What changes when you have them

• Breaking changes are caught at the source. A schema change that violates the contract fails the producer’s deployment, instead of silently breaking a dashboard three days later.
• Incidents have an owner. When a check fails, the alert goes to the producer who can fix it.
• Audits get easier. Contracts, test history and lineage together show an auditor how a reported figure is controlled.

Start small: the ten datasets that matter most

Contract programs fail when they try to cover everything. Instead:

1. List your critical data elements. The datasets behind regulatory submissions, board metrics, finance close and production models. For most organizations this is ten to thirty tables.
2. Name an owner for each. A person, not a team mailbox.
3. Write the contract as code. Schema plus a short set of tests: freshness, volume, nulls in key fields, one or two business rules.
4. Run the checks on every load. Fail loudly, alert the producer.
5. Measure. Count incidents caught before reaching consumers. That number is your business case for expanding.

Tools you probably already have

You don’t need a new platform to start. Most teams can express contracts with:

• dbt model contracts and tests;
• Delta Live Tables / Lakeflow expectations on Databricks;
• Snowflake data metric functions;
• open-source frameworks such as Great Expectations or Soda.

Add lineage from your catalog (Unity Catalog, Snowflake Horizon, Microsoft Purview) so a failed check shows which reports and models are affected.

What to tell the producers

Contracts only work if producing teams accept them. Frame it as protection for them: fewer emergency messages from finance, clear rules about what they can change freely, and a defined process for what they can’t.

The board-level version

“Every figure in our regulatory and board reporting is checked automatically at every load, and we know who owns each one.” That’s a sentence most CDOs would like to be able to say. Data contracts on the critical few datasets get you there in weeks, not years.

Our data quality and governance work starts with exactly this: critical data elements, owners, contracts and tests, implemented in your platform.