Skip to content

Every dataset profiled. Every load validated.

Data lands as an open Delta table, gets profiled the moment it arrives, and is validated against rules on every load. Quality is not a report you check — it's a state the data travels with.

Land it once. It's a Delta table now.

Upload CSV, Parquet or JSON, sync a database, or point a connector at a SaaS tool — sixteen source types from Postgres and Snowflake to HubSpot and Google Ads. Whatever the door, the result is the same: an open Delta table, versioned from the first row.

Ten datasets on the lakehouse — uploads, logs, events, a pipeline output and a model's scores — every one tracked and healthy
TEN DATASETS ON THE LAKEHOUSE — UPLOADS, LOGS, EVENTS, A PIPELINE OUTPUT AND A MODEL'S SCORES — EVERY ONE TRACKED AND HEALTHY

Full SQL, run where the data lives.

DataFusion — a Rust query engine — reads the tables in place. Reference any dataset by name in quotes, run SELECT or write with INSERT, DELETE and MERGE, export the result or save it as a new dataset. No warehouse in the middle, no export step.

Weekly net revenue over the orders table, executed by DataFusion: 12 rows in 29 milliseconds
WEEKLY NET REVENUE OVER THE ORDERS TABLE, EXECUTED BY DATAFUSION: 12 ROWS IN 29 MILLISECONDS

Profiling starts the moment data lands.

Every column is profiled automatically on every load: types, null rates, distinct counts, sampled values. No configuration step. The profile is the first thing you see on a dataset, and the baseline every rule is written against.

The orders dataset: 5,000 rows, nine typed columns with sampled values
THE ORDERS DATASET: 5,000 ROWS, NINE TYPED COLUMNS WITH SAMPLED VALUES

Rules run on every load.

Sixteen rule types, declared per dataset and evaluated against real loads, not samples. Each run records pass or fail, the violation count and the rows behind it — so a failure is a finding, not a hunch. A load that would change the schema is held at the door until someone confirms it.

16 RULE TYPES · EVALUATED ON SCHEDULE · FULL RUN HISTORY

  • Completeness + uniqueness No unexpected nulls, no duplicate keys in the columns that matter.
  • Ranges, patterns, accepted values Values stay inside the bounds, formats and sets you define.
  • Aggregates Mean, sum, stddev, distinct and row counts land inside the expected band.
  • Freshness + volume Data arrived when it was supposed to, in roughly the quantity expected.
  • Schema change Columns and types still match the contract; a drifted load is held for review.
  • Custom SQL + chained rules Any SELECT you can write becomes a rule; rules can gate other rules.
Six rules on the orders dataset: five passing, one failing on discount_pct completeness
SIX RULES ON THE ORDERS DATASET: FIVE PASSING, ONE FAILING ON DISCOUNT_PCT COMPLETENESS

Where this line interchanges.

When do quality checks run?

Column profiling runs automatically on every load — no configuration. Validation rules run on the schedule you set per rule, and every evaluation is recorded in the history with its pass/fail result and violation count.

What rule types does AZ-Five support?

Sixteen types: completeness, uniqueness, accepted values, ranges, patterns, length, five aggregate checks, freshness, volume, schema change, custom SQL and chained rule pipelines — declared per dataset, each with its own schedule and history.

What happens when a schema changes?

The load is held. AZ-Five shows you exactly which columns were added, dropped or retyped and asks for explicit confirmation before the change merges. Nothing lands silently.

How do downstream users see quality state?

Health propagates through lineage. A failing rule surfaces as a health badge on the dataset, on every measure defined over it, and on every chart and dashboard that uses those measures.

Catch it at the door, not on the dashboard.

Upload one dataset and watch it get profiled. Your first validation rules take minutes to add.

AZ-Five