PATTERN Cited by 2 sources

Data contract¶

A data contract is a formal, explicit agreement between the producer of a data product and its consumers that specifies what the product is, how it behaves, who may use it, and who is responsible for it. It is the artifact that implements federated governance: it lets domain teams own their data while still guaranteeing that cross-domain consumers can rely on it. The producer authors it, but it "should be designed with the consumer in mind … framed in a way that is consumable by all types of users." (Source: sources/2026-09-03-databricks-building-high-quality-and-trusted-data-products-with-databricks)

The contract is produced in the Design phase of the data product lifecycle and becomes the reference the product is tested against during Creation and enforced/monitored against during Operate & Govern.

What a contract carries¶

A typical data contract specifies:

Data description — name, description, source systems, attribute selection.
Schema & formats — tables, columns, plus anonymization/encryption info, filters, masks; and the formats for semi-structured and unstructured data.
Usage policies — tags, PII markings, guidelines, data residency.
Data quality — the quality checks/constraints applied and the quality metrics exposed.
Security — who is allowed to use the product.
Data SLAs — freshness (last update), expiration dates, retention time.
Responsibilities — owner, maintainer, escalation contact, and the change process for evolving the product.

Supporting assets (sample notebooks, dashboards) commonly ride alongside the contract to speed consumer adoption.

Why it is a distinct pattern¶

A data contract is broader than a schema. A schema (or a schema-as-contract) pins down shape and types; a data contract also pins down SLAs, access, quality thresholds, ownership, and the change process. The "change process" and "data SLA" fields are what let consumers depend on a product safely: they make evolution a negotiated, versioned event rather than a silent break. This is the data-plane analogue of an API stability contract.

How it enables federated governance¶

Central governance defines the template for contracts (what fields are mandatory, which usage-policy vocabularies are allowed); domain owners fill in the contract for their product. A cross-functional governance team (a Center of Excellence) standardises the contract-framing process and helps decide who may consume a product. The result is central standards + decentralised authorship — the governance posture every data mesh needs.

On Databricks¶

The contract's fields map onto platform features: schema/quality live in Delta Live Tables expectations and constraints; usage policies and PII tags live as Unity Catalog tags; SLAs are monitored by Lakehouse Monitoring; access rules become catalog grants. Notably, the post concedes designing the contract itself has no native feature — it is done outside the platform and the result is documented in Unity Catalog after publication.

Seen in¶

sources/2026-09-03-databricks-building-high-quality-and-trusted-data-products-with-databricks — full attribute list (description, schema/formats, usage policies, quality, security, SLAs, responsibilities); framed as the mechanism for federated governance and the reviewed artifact in the certification workflow.
sources/2026-09-11-aws-from-zero-shot-forecast-to-purchase-order-with-agentcore — the inter-agent form of the pattern: each agent in the sequential chain outputs a typed JSON structure the next consumes (a representative Forecasting→Reporting contract carries forecast quantiles, order_decision, anomaly_flags, a first-class rationale, and covariates_used so the Preprocessing agent's covariate choice is auditable). Framed as the fix for the most common multi-agent failure mode — "implicit coupling through unstructured text, where one agent returns a paragraph and the next tries to extract numbers from it." Explicit JSON contracts make the handoff machine-readable and human-debuggable.

concepts/data-mesh — the contract is one required output of the Design phase.
data-product-certification — a steward reviews the proposed contract before CI/CD deploys the product.
schema-as-cross-system-contract — the narrower, shape-only ancestor of a data contract.
concepts/schema-evolution — the "change process" field governs this.
concepts/data-mesh — federated governance is the mesh's central-standards-plus-domain-ownership posture.