# Data Quality & Contracts

Every source is governed by an Open Data Contract Standard document, and every sync checks the schema it extracts against that contract.

## 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.

Links: [Join the waitlist](/waitlist/)

## Contracts as code

Amfelt generates an ODCS document for each source. You keep it in Git, and rerunning discovery shows what changed.

## Profiles, not records

The recommendation advisor sees a profile of each table, not its records: record counts, null ratios, distinct counts, and the earliest and latest value of each date and time column. The agent computes the profile from the records it loads; an advise run on a PostgreSQL source computes it in the database.

## Validation on every sync

Each sync checks the extracted schema against the contract and reconciles record counts in staging. On PostgreSQL targets, your SQL rules run 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.

Links: [Data Movement](/platform/data-movement/)

## 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.

Links: [Read the article](/blog/understanding-your-data-platform/)

## FAQ — Common questions.

### What is an ODCS document?

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.

### Where do quality rules come from?

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.

### Can a quality rule change my data?

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.

### What happens when a check fails?

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.

### Is there a library of pre-built rules?

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.

### Where do the contracts live?

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.

Links: [Join the waitlist](/waitlist/)