Schema contracts are solved. Quality contracts aren't.
dbt, schema registries, and CI checks nailed the schema half of data contracts. The quality half is still empty — and that's the half that breaks in production.
The data-contract ecosystem has quietly split in two.
One half — the schema — is basically solved. dbt model contracts, schema registries, and tools that fail your CI when a column type changes all do a good job of guaranteeing *shape*: the columns exist, the types match, nothing got renamed out from under you.
The other half — the quality — is still empty. A contract that promises a status column says nothing about whether status is ever null, whether it only contains the values you expect, or whether yesterday's load was complete. That's the half that pages you at 2am.
Where DQHub fits
We're not building another data-contract format. The standard has already won: the Open Data Contract Standard (ODCS), governed by the Linux Foundation. We speak it natively.
What ODCS has — and what nobody has filled well — is a quality block on every table and column. That block is exactly what DQHub has always been: curated, multi-engine data-quality rules. So our role is simple:
DQHub fills the ODCS quality block, and compiles it to every engine.
What that means in practice
- Export any pack as an ODCS contract. Pick a pack, choose the ODCS format, and download a schema-valid
*.odcs.yamlwith the quality block filled in. Browse packs → - One definition, every engine. The same contract compiles to Soda, dbt, Great Expectations, SQL, and Spark. No rewriting, no translation.
- Start from your data, not a blank page. Generate a contract from a CSV in under a minute — no database connection required.
- Certified, audit-ready templates. HIPAA, PCI, ISO 20022, AML/KYC and more, with retention and ownership built in. See certified templates →
Schema contracts told you the shape. Quality contracts tell you whether to trust the data. That's the half we're here for.