Data Quality & Contracts
Monitor the health of your data and define pass/fail contracts on tables to catch freshness, volume, and completeness issues automatically.
Last reviewed July 13, 2026
Data Quality and Data Contracts work together to keep your warehouse trustworthy. Data Quality is the monitoring side — a live view of the health of your data based on checks that run automatically as data flows in. Data Contracts is where you define those checks — pass/fail assertions attached to specific tables, with tiers, SLA targets, and alert routing.
Open Data, expand Governance, then choose Quality or Contracts.
Quality vs. Contracts
| Page | What it is |
|---|---|
| Data Quality | The observability view. Shows every active check, its latest pass/fail status, when it last ran, and a summary of passing, failing, and errored checks with an overall pass rate. |
| Data Contracts | The definition side. A contract attaches to a table (a “subject” from the Data Catalog) and bundles the checks you want enforced on it, plus a tier, optional SLA targets, alert routing, and an owner. |
Checks are observational, not blocking — a failing check never stops a sync or blocks downstream pipelines. It records a result, surfaces in the app, and can alert your team. Data quality is a signal, not a gate.
Creating a contract
Contracts attach to catalog subjects. You can create one from the Contract tab on any table’s detail page in the Data Catalog, and manage all contracts from the Data Contracts list.
Each contract includes:
- Tier — T1 (Critical), T2 (Important), or T3 (Exploratory), matching the Data Catalog tiers. Choosing a tier for a new contract seeds a sensible default set of checks, which you can edit freely. Changing the tier of an existing contract does not re-seed its checks.
- Checks — the pass/fail assertions themselves (see below).
- SLA (optional) — an availability target (%) and a recovery target (minutes) documenting the expectations for this table.
- Alert routing (optional) — where failure alerts go, such as a connected Slack workspace.
- Owner (optional) — the team member responsible for this table’s health.
Contracts can be deactivated (checks stop running, history is kept) or permanently deleted (removes the contract, its checks, and all result history — irreversible).
Check kinds
A contract can combine any of these checks:
| Check | What it asserts |
|---|---|
| Freshness | The table has been written to within a maximum age (hours). By default this reads the connection’s last sync time; it can instead check the maximum value of a timestamp column in the table. |
| Row count | The table’s row count is at or above a minimum (and optionally below a maximum). |
| Schema | Required columns exist, forbidden columns do not, and specified columns have the expected data types. |
| Null rate | A column’s share of NULL values stays below a threshold (e.g., 0.05 = 5%). |
| Empty string rate | A column’s share of NULL or blank string values stays below a threshold. |
| Null keywords | A column’s share of literal placeholder values (e.g., n/a, nil, none — configurable) stays below a threshold. |
| Delta row count | The table’s row count stays within a tolerance (%) of another table’s — useful for comparing a raw table against its transformed counterpart. Supports an optional shared WHERE clause. |
| Custom SQL | An arbitrary query holds: it returns no rows, returns a single true value, or returns a scalar that satisfies a threshold (e.g., = 0). Useful for cross-table invariants. |
How checks run
Checks run automatically after each sync that writes to a table with an active contract. They can also be triggered on demand. Each run produces one result per check:
| Status | Meaning |
|---|---|
| Passed | The assertion held. |
| Failed | The assertion did not hold — the data is in violation. |
| Error | The check itself could not run (e.g., missing table, malformed SQL). Tracked separately from failures. |
Every result is stored with the expected value, the actual value, and a message — so a failing freshness check reads as “expected ≤ 6h, actual 12h.”
The Data Quality page
The Data Quality page summarizes all active checks across your workspace:
- Summary stats — Passing, Failing, Errored, Never Run, and the overall Pass Rate
- Check list — each check with its latest status, kind, the subject it monitors (linked to its catalog page), the latest expected/actual detail, and when it last ran
If the page is empty, add a contract to a catalog subject to start monitoring it.
Alerts
When a check fails, Vendo can send a Slack alert to your connected workspace — one batched alert per table per sync, listing every failed check with its expected and actual values. Configure this in the contract’s Alert routing section; it requires a connected Slack workspace.
Failures also surface in the app:
- The Data Quality page shows the failing check with its latest result.
- The table’s Health card in the Data Catalog shows its contract tier alongside observed freshness, row count, and schema information.
Relationship to the Data Catalog
Data Quality builds on the Data Catalog:
- Contracts attach to catalog subjects — the tables the catalog tracks across your sources.
- Contract tiers are the same T1/T2/T3 classification used throughout the catalog.
- Each table’s catalog detail page includes a Contract tab for defining or editing its contract, and a Health view combining pipeline observations with contract status.
Prioritize contracts on your Tier 1 tables first — the ones feeding production reports and downstream tools — then expand coverage as needed.