Schema Drift — When the Column Renames Itself

You're running a pipeline. Everything validates. Then one Monday morning, your user_id column is null for 40% of your records.

No errors. No alerts. Just nulls.

What happened: upstream, a developer renamed user_id to userId in their event schema. Your ingestion pipeline passed it through — strings pass type checks. Your transformation layer doesn't error on null joins — it just returns empty results. Your dashboard shows zero active users. Your CTO is asking questions.

This is **schema drift**. The most common and least detected data quality failure mode. It happens when upstream teams change column names, types, or structures without notifying the data team. Your validation catches nulls and type mismatches — but it doesn't catch a column that exists but now contains something different.

The fix isn't schema registries

Most teams respond by adding a schema registry — Avro, Protobuf, JSON Schema validation at ingest. It helps. But it's a coordination overhead tax on every upstream team, and it only catches what you've explicitly declared.

Schema drift slips through because the column exists, the type is correct, and the value isn't null. The downstream join just quietly returns wrong results.

Distribution Shift — When Your Metrics Lie Quietly

Your conversion rate dashboard shows 3.2%. It's been 3.2% for six months. That's normal.

Except last week, it started averaging 0.3% — and nobody noticed for four days.

What changed? Nothing in the pipeline. The null rate is fine. The type checks pass. The row count looks normal. But the distribution of the converted flag shifted — a product change caused a downstream funnel to flip, and now 97% of sessions are being tagged incorrectly upstream.

Your null check: PASS. Your type check: PASS. Your range check on 0-100%: PASS.

But your data is broken.

This is **distribution shift**. The metric is in the valid range but the underlying data has changed. Static thresholds miss this. Monotonicity checks miss this. You need a baseline profile, and you need statistical comparison against it.

Why column-level profiling catches what row-level checks miss

Most data quality tooling checks: is this null? Is this the right type? Is this in range?

Column-level profiling asks: what's the distribution of this column today, and how does it compare to last week? This week? Last month?

A drop from 3.2% to 0.3% conversion looks fine in a range check (0.3 is between 0 and 100). But it's an 88% distribution change — your users are telling you something is different.

Delayed Propagation — When Your Dashboard Shows a Ghost

It's Tuesday morning. Your dashboard shows revenue for Monday: $847,000. Looks current.

The actual data for Monday stopped arriving at 11pm Monday night. The pipeline broke silently — no error, no alert. Your Monday revenue is $0. The dashboard shows $847,000 because it cached yesterday's numbers and nothing triggered a refresh.

Six hours later, someone notices that Monday's numbers don't match the Stripe dashboard. You spend three hours investigating. The fix is a one-line configuration change that took 45 seconds.

This is **delayed propagation** — the silent data quality failure that happens when data arrives late but displays as current. No error flag, no alert, no indication that your pipeline is running on stale data. Just a dashboard that tells a story that isn't true.

The "stale but valid" problem

Data quality has a specific blind spot: it validates that data is correct, not that it's current. A dashboard showing yesterday's data with today's timestamp is technically valid and will pass most quality checks.

The fix: not just freshness thresholds (alert if data is older than X hours), but proactive freshness monitoring. If your revenue data hasn't updated in 8 hours, the dashboard should show a staleness indicator — not silently serve yesterday's numbers as current.

The common thread

All three of these patterns have the same characteristic: they **pass every traditional data quality check** and fail silently in production.

Schema drift passes type checks. Distribution shift passes range checks. Delayed propagation passes validation.

This is why most data teams discover these failures from stakeholders, not from monitoring. The tools catch the failures you know to look for — and miss the ones that arrive without an error message.

Siftra monitors column-level distributions, tracks freshness at the table and column level, and catches statistical anomalies that static rule-based validation misses. If your pipeline has been producing broken data for the past three days without raising a single error, Siftra will tell you — before your CTO does.