Dataset Drift & QA Monitor

You ship a scraper. It works. Weeks later, the schema shifts — a field renames, a new nullable column appears, the price field starts coming back as a string instead of a number. Your downstream pipeline silently produces garbage until someone notices. Dataset Drift & QA Monitor catches it on the next run.

What it checks

• Schema fingerprint — deterministic hash of field names + types. Changes = alert.
• Row count delta — absolute and % change vs. baseline. Sudden drops or spikes = alert.
• Null rates — per-field null %. Threshold breach = alert.
• Numeric distributions — min/max/mean/stddev for numeric fields. KS-test style drift detection for continuous variables.
• Categorical distributions — top-k frequency per category field. New categories or massive shifts = alert.

How it works

Give it an Apify dataset ID or any JSON endpoint. It fetches a sample (configurable, default 1000 rows), computes the profile, compares against the stored baseline, and emits a structured report with pass/fail flags and a drift score. On first run it establishes the baseline. Every subsequent run diffs against it.

{
  "datasetId": "cynix_dev~fx-rates-history/default",
  "sampleSize": 1000,
  "thresholds": { "rowCountPct": 0.2, "nullRatePct": 0.05, "driftScore": 0.3 }
}

The report is a single dataset record per run — easy to feed into an alert webhook, a dashboard, or the actor's own "notify on drift" toggle.

Why not Great Expectations / dbt tests / Soda?

Those are excellent for warehouse tables. This is for the ingestion boundary — the moment raw data lands, before it hits your warehouse. Different problem, different tool.