Solutions · Data Quality & Contracts
Every Sync Checked Against Its Contract.
Amfelt generates an Open Data Contract Standard (ODCS) document for each source, for you to keep in Git. Every sync checks its schema against that contract and, on PostgreSQL targets, runs your quality rules too.
How It Works
Contracts Generated for You and Checked on Every Sync.
Discover the source
Discovery reads the source’s structure: its tables, columns, and types, and for a database its keys and constraints.
Generate the contract
That structure becomes an ODCS document per source (schema, types, and constraints), versioned in Git once you commit it.
Validate on every sync
Each sync checks the extracted schema and reconciles record counts in staging. On PostgreSQL targets your SQL rules run too, and a critical violation fails the run.
Handle drift
Run discovery again and each schema change is graded patch, minor, or major against the contract. Applying changes under a policy you set is on the roadmap.
Quality Where It Belongs: In the Pipeline.
Bolt-on quality tools run as a separate job against your data platform. Amfelt runs the checks as part of every sync. It validates the schema as data is read and reconciles the record count once each table lands in staging. On PostgreSQL targets it also runs your rules against the landed table, so a problem shows up on the run that caused it.
From the Blog
I Had to Read the Code to Understand the Data Platform
An incomplete source inventory meant assessing integration code before planning a global warehouse.
FAQ
Common Questions.
The Open Data Contract Standard is an open, vendor-neutral format that describes a dataset’s schema, quality expectations, and ownership. Amfelt generates one per source, and each discovery from the control plane updates it.
Structural checks need nothing from you: column presence, types, required columns, and primary-key columns are checked against the contract, and record counts against the extract. Business rules are yours to declare: SQL queries in the contract itself, each returning one number that is checked against operators such as
mustBeLessThan and mustBeBetween. A single-value operator set to 0 is ignored today, so write a zero bound with mustBeBetween. Because rules live in the contract, they are versioned in Git with every other change and can be reviewed as diffs.No. Rules run inside a read-only transaction that the database enforces, so a check cannot change what it validates. On a target where Amfelt cannot yet open a read-only transaction, DuckDB today, a rule is not run, and the agent’s log reports it as not evaluated.
For your SQL rules, severity decides; the structural checks only warn. A
critical violation fails the run, and the failed step in the run’s checkpoints names the rule, the table it ran on, and the value its query returned. Anything lower adds a warning to the run, and the agent’s own log names the rule. A rule returns a single value, not the records behind it.Not yet. Today you write rules as SQL. A library of standard checks, written for each database, and rules on individual columns are on the roadmap.
In Amfelt’s catalog as soon as discovery runs, and in your Git repository once you commit them, next to the rest of your pipeline configuration: diffable and versioned like code.
Make Quality a Property of the Pipeline.
Join the waitlist to hear when Amfelt opens to more teams.