← The Data Eye

Module 1: The Data Eye

Why a query can run perfectly and still be wrong — and how to see it.

Silent corruption: the wrong number that runs

A security bug usually does something visible — a leak, a crash, an exploit. A data-quality bug is quieter: the query runs, returns rows, the dashboard renders, and the number is simply wrong. Revenue is 1.4× too high because a join fanned out. A cohort is empty because NOT IN met a NULL. Nothing errors. Nobody notices for a quarter.

This is a perceptual skill, not a knowledge one. You already know what a join is. The hard part is seeing, in the third CTE of a 200-line dbt model at 4pm, that the join key on the right side isn’t actually unique — while not flagging the ten correct transforms next to it.

The dangerous artifact is syntactically clean, runs fast, and returns plausible numbers. Fluency is what makes it dangerous. Train your eye on the shape of corruption — fan-out, NULL semantics, wrong grain — not on whether the SQL "looks" right.

This course is reps, not lectures

Each module pairs short readings with drills: real AI-generated SQL, dbt models, and pipeline snippets you judge under a timer — Ship, Flag, or Escalate — then immediate feedback on the exact wrong number it would produce and the distractor that made it look fine.

  • Ship — you’re confident the transform is correct.
  • Flag — there is a definite correctness bug; block it.
  • Escalate — correctness depends on data/semantics you must verify against the source or spec (e.g. is this key actually unique?).

Calibrated trust, not paranoia

A reviewer who flags every complex query gets ignored — and complexity is not a bug. A reviewer who ships everything corrupts the warehouse. The goal is the narrow band between, measured on two axes at once:

  • Catch rate — of the genuinely-wrong transforms, how many did you stop?
  • False-alarm rate — of the correct transforms, how many did you wrongly block?

About a third of the drills are safe-but-scary: a fan-out that’s correctly de-duplicated, a COUNT(col) that’s intentional, an incremental that’s properly merged, a window function an AI linter calls "non-deterministic". Flag those and you lose points.

The scan pattern

  1. Grain — what is one row of each input? What grain does the output claim to be?
  2. Keys — is every join key unique on the side you think? (the #1 silent bug lives here)
  3. NULLs — can any joined/filtered/summed column be NULL, and does that change the meaning?
  4. Idempotency & types — does a rerun duplicate rows? Is money a FLOAT? Is a ratio integer division?
Watch the AI itself: it will sometimes over-flag a correct transform ("this window function is non-deterministic!") and sometimes confidently ship a fan-out. Your job is to overrule it in both directions.

Ready? Hit the warm-up drill below. Four cards, two of them safe.

Drill — The Data Eye

Judge each artifact. You are scored on calibration: catches vs false alarms.

CARD 1 / 4catches 0/0false alarms 0/0
AI-generated · SQLSQL Review
Prompt to the AI » "Total revenue per customer. Orders join to a payments table by customer_id."
SELECT o.customer_id,       SUM(o.amount) AS revenueFROM orders oJOIN payments p ON p.customer_id = o.customer_idGROUP BY o.customer_id

Capstone: the Capstone: Calibration Exam (16 cards) from The Data Eye unlocks once modules are complete.