Data Contract

A data contract explicitly defines the structure, types, and constraints of the data being exchanged. This includes column names, data types (e.g., INT64, STRING), nullability, and allowed value ranges. By validating data against this schema at the producer boundary, the contract prevents malformed records from entering downstream systems. This is a shift from reactive data quality monitoring to proactive interface guarantees, ensuring that a consumer never receives a string where it expects a timestamp.

Beyond structure, a contract defines the real-world meaning of each field. It specifies the business logic, units of measurement, and calculation methodology. For example, a field named revenue must be defined: is it in USD or EUR? Is it gross or net? Does it include deferred revenue? This semantic layer eliminates the ambiguity that leads to conflicting reports and incorrect analyses, ensuring all consumers interpret the data identically.

A robust data contract includes measurable quality and delivery guarantees. These SLOs define the quantifiable promises a producer makes to its consumers, such as:

• Freshness: Data will be delivered within 15 minutes of the source event.
• Completeness: No more than 0.1% of expected records will be missing.
• Accuracy: The total_amount field will match the source system within a 0.01% margin of error. These metrics are programmatically monitored, triggering alerts when a contract is breached.

Data schemas and semantics inevitably change. A data contract must have an explicit versioning strategy (e.g., semantic versioning) to manage this evolution without breaking consumers. The contract defines a deprecation policy, such as supporting a deprecated field for two versions before removal. This allows producers to evolve their systems while giving consumers a clear, non-negotiable window to migrate, preventing the chaos of unannounced breaking changes.

The contract is not a PDF or a wiki page; it is an executable artifact stored as code (e.g., YAML, JSON, Protobuf). This allows for automated enforcement in CI/CD pipelines. A producer's deployment can be blocked if its output schema does not match the contract. Tools like Apache Avro, JSON Schema, and custom frameworks can parse this specification to auto-generate validation logic, documentation, and even consumer client libraries, making governance an automated process.

A data contract explicitly assigns ownership to a specific team or service. The producer is accountable for meeting the contract's SLOs and communicating changes. This moves away from the 'data swamp' model where no one is responsible for quality. The contract becomes a shared interface between a data product owner and their stakeholders, fostering a product-thinking mindset where data is treated as a reliable, maintained asset rather than a byproduct of operations.

A precise, measurable target for a service's reliability or performance. In data contracts, SLOs define the quantitative quality guarantees a producer commits to.

• Example: "99.9% of records delivered within 5 minutes of source commit"
• Example: "Null rate on customer_id field < 0.01% per window"
• Paired with Service Level Indicators (SLIs) for measurement

SLOs transform vague promises into mathematically verifiable commitments.

A packaged, self-describing data asset treated as a first-class product with a dedicated owner, defined interface, and lifecycle. A data contract is the API specification for a data product.

• Includes metadata, documentation, and access controls
• Owned by a cross-functional domain team, not a central IT group
• The contract defines the product's guaranteed interface contract

Data mesh architectures treat contracts as the binding agent between autonomous domain products.

A formal agreement specifying the acceptable thresholds for dimensions of data quality: accuracy, completeness, consistency, timeliness, and uniqueness. This is the core of a data contract's enforcement logic.

• Accuracy: Values reflect real-world entities correctly
• Completeness: Required fields are non-null within tolerance
• Timeliness: Data arrives within the freshness window

Breaching an SLA triggers automated alerts and can halt downstream pipelines.