Data Contracts and Schema Evolution

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Data contracts and schema evolution policies tell agents whether an upstream change is compatible with downstream consumers.

## Core Explanation

Schema changes are not just metadata edits. Adding, removing, or changing fields can break consumers, dashboards, feature pipelines, or model training jobs. Agents need to inspect schema versions, compatibility mode, consumer expectations, and contract enforcement before deciding whether a data change is safe.

Contracts can include column names, types, constraints, freshness, ownership, and quality rules. A contract is most useful when the build or ingestion path enforces it, because the agent can cite a failed rule instead of inferring breakage from downstream symptoms.

## Source-Mapped Facts

- Confluent Schema Registry documentation describes compatibility checking by versioning each schema and comparing new schemas with previous versions. ([source](https://docs.confluent.io/platform/7.7/schema-registry/fundamentals/schema-evolution.html))
- AWS Glue Schema Registry documentation says compatibility modes form the contract between applications producing and consuming data. ([source](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html))
- dbt documentation describes model contracts as allowing users to define columns, data types, and constraints that dbt enforces. ([source](https://docs.getdbt.com/docs/mesh/govern/model-contracts))

## Further Reading

- [Confluent Schema Evolution](https://docs.confluent.io/platform/7.7/schema-registry/fundamentals/schema-evolution.html)
- [AWS Glue Schema Registry](https://docs.aws.amazon.com/glue/latest/dg/schema-registry.html)
- [dbt Model Contracts](https://docs.getdbt.com/docs/mesh/govern/model-contracts)