Overview
When you manage data as a product, consumers need more than a table name. They need a clear, dependable interface. Data contracts are the agreements that define that interface: what a product exposes through its output ports, what quality and freshness consumers can rely on, and how changes are communicated before they land downstream.
In Blindata, contracts live inside the Data Product Descriptor and are authored in the Data Ops Builder. Producers and consumers align while the product is still in development. Open Data Contracts (ODC) quality annotations let product owners declare quality rules on the contract itself, versioned in Git next to ports, schemas, and lifecycle configuration.
Contracts are the producer–consumer agreement. Computational governance policies are separate: they are the platform-level controls that govern registration, version publishing, and stage transitions across the portfolio. Policies can check that descriptors and contracts meet organizational standards; they do not replace the contract. See Computational Governance Policies.
Adoption is modular. Start with schema and ownership on a single product, then add SLAs, quality annotations, and monitoring as maturity grows, without forcing every domain through the same rollout.
Features
Blindata supports the full contract lifecycle: definition, shift-left authorship, quality expectations, and ongoing monitoring.
Descriptor as contract
Express contracts in the Data Product Descriptor (DPDS): a tech-agnostic, declarative format for ports, schemas, metadata, and quality expectations, versioned in Git with the product.
Ownership
Assign producer and consumer responsibilities through Stewardship & Responsibilities, so every contract has clear accountability on both sides.
Quality annotations (ODC)
Attach Open Data Contracts quality metadata in the Builder so product owners declare data quality rules on the contract, alongside ports and schemas, and keep them versioned with the descriptor.
Prevent breaking changes
Catch schema drift, removed fields, and incompatible updates before consumers are affected, using lifecycle checks on new versions of the contracted interface.
Platform policy control
Optional computational policies at the platform level can validate that descriptors and contracts meet global standards before registration or promotion. Lifecycle control, not the contract itself. See Computational Governance Policies.
Monitoring
Monitor the data assets bound to each contract with Observability & Quality probes, so agreed SLAs and quality thresholds are tracked in production, not just on paper.
How to
Attach contracts to input and output ports while designing a data product, not after it ships. In the Data Ops Builder, the descriptor is the single source of truth for how a product presents itself to consumers. Aim for a descriptor that is:
- Tech agnostic: compatible with any stack; describes what data looks like, not how it is produced.
- Incrementally adoptable: start with schema and ownership, add SLAs and quality rules when teams are ready.
- Declarative and modular: each port and contract element is a discrete, composable piece of the descriptor.
- Extendable: custom properties and links to business glossary terms keep contracts aligned with your shared ontology.
Save commits to the linked Git repository as you go, so the catalog and marketplace receive the same interface teams designed.
Use data contract quality annotations aligned with the Open Data Contracts (ODC) specification to declare quality expectations on the contract itself. In the Builder, product owners attach quality metadata so rules to monitor the product sit next to ports, schemas, and DevOps configuration.
Those annotations are versioned with the rest of the descriptor. Edit them as the product evolves, validate before save when your tenant policies require it, and keep quality intent with the interface instead of in a separate wiki that goes stale.
Promote products through the Data Ops lifecycle: registration, version publishing, and stage transitions. The contracted interface travels with each immutable release.
Platform teams can optionally deploy computational governance policies that fire on those lifecycle events: for example descriptor completeness, naming conventions, backward compatibility of port schemas, or semantic links to the glossary. Policies control what the platform allows to progress; they complement contracts, they do not define them. Details on Computational Governance Policies.