Quality & root cause: trust the number before you explain it

Your team already has the data-quality-audit and root-cause playbooks — the worked recipes for running a systematic fit-to-use check on a file and for tracing a metric’s move back to its real cause. Each is a good move, done once. This module is the layer that turns those two moves into a discipline every number clears before it leaves the folder: a quality gate that catches the avoidable failures before a dataset feeds something that matters, and a root-cause habit that rules out a data artifact before it ever gets to blame the business.

It’s Module 3 of the certifiable Data & Analysts track, and it inherits everything you built in Module 1 and Module 2. Your dataset-profile habits and metrics.md definitions from M1 are exactly what a quality audit formalizes into stated, testable rules; the query discipline from M2 is what makes every check and every breakdown re-runnable by someone who didn’t build it. M1 and M2 taught you to trust a file and join it cleanly; M3 teaches you to defend a number — to prove, on demand, that it’s both clean and correctly explained.

A number that reaches a stakeholder has cleared two gates, whether anyone named them or not: is the data this number is built on actually fit to use, and is the explanation for why it moved actually true? Skip the first gate and you ship a confident number built on a broken join. Skip the second and you ship a confident story that turns out to be a tracking change wearing a business narrative. Most teams never name either gate, so both fail silently — the audit nobody ran, the cause nobody ruled out. This module is where you name them, run them, and prove you can.

Why quality and root cause are the same discipline

Profiling tells you what a file contains. A quality audit tells you whether it’s fit to use — a heavier, rule-bound check you reach for when the cost of being wrong is high enough that “it looked fine” won’t survive a challenge. Root cause tells you whether a number’s story is true — whether the metric that moved actually reflects the business, or reflects something that broke upstream of the business entirely. They look like different skills. They’re the same discipline pointed in two directions: both refuse to accept a number at face value, and both insist on a stated rule or a confirming check before a conclusion ships.

The reason this module bundles them is that in practice they chain. A quality audit run before a number reaches a report routinely surfaces the anomaly that a root-cause investigation then has to explain — that’s not a coincidence, it’s the audit doing its job. And a root-cause investigation that skips its own data-artifact check is really skipping a miniature quality audit on the one slice of data the question is about. Master both together and you stop treating “is this data good?” and “why did this number move?” as separate emergencies — they’re the same two questions, asked at different points in the number’s life.

Two failure modes this module exists to prevent, both quiet by nature:

• The unaudited number. A dataset feeds a board figure, a recurring report, or a model with nobody having checked completeness, validity, uniqueness, referential integrity, freshness, or drift against a stated rule. The output still looks like a normal number — confident, formatted, on time — until someone downstream discovers the duplicate keys or the orphaned foreign keys that quietly inflated it.
• The unverified explanation. A metric moves, someone needs an answer before the meeting, and the first plausible story that fits gets reported as fact. Half the time that story is real. The other half it’s a missing day of data, a tracking change, or a metric definition that drifted — and reporting it as a business conclusion is the single most expensive analyst mistake, because it gets forwarded into decisions and budgets before anyone checks.

The quality audit — rules first, verdict last

The playbook gives you the steps: check the dimensions, build the scorecard. Mastery is the judgment in two places the recipe can’t supply — stating rules precise enough to test, and turning a list of findings into a verdict someone can act on.

• An audit with no stated rules is just a profile with extra steps. “Completeness looks okay” is an impression. “order_id is unique and never null; amount >= 0; status is one of {paid, pending, refunded}; customer_id must exist in customers; data covers through yesterday” is a rule set — and the difference is that a rule set has a pass/fail a reviewer can check without re-deriving your judgment. Write the rules down and ratify them with a stakeholder before you test anything against them, because the rules are the actual audit; the checks that follow just execute them.
• Run all six dimensions, not the two that are easy. Completeness and validity are the cheap, high-yield checks — most teams stop there. Uniqueness, referential integrity, freshness, and drift are the ones that catch what actually corrupts a downstream report: the duplicate key that double-counts, the orphaned foreign key that silently drops rows out of a join, the stale load that’s a week behind without anyone noticing, the schema or distribution shift that looks like a business trend but is really a pipeline change. Skipping the structural checks because the completeness check came back clean is exactly how a confident wrong number gets through.
• Severity is what keeps the scorecard honest in both directions. Every finding gets a severity — blocker, warning, or note — because a wall of red findings with no severity gets ignored by the time it matters, and a scorecard that calls everything fine waves real problems through. An 18%-null region column might be entirely expected; one duplicated primary key on the revenue table is a blocker. Forcing the split is what makes the scorecard a decision instrument instead of a list.
• The audit surfaces; it never silently fixes. Deduping a key, dropping out-of-range rows, or resolving a contradiction changes the data. That’s a call an owner makes on the record, never something that happens quietly to make the scorecard turn green. Flag every issue with a count and an example, propose the fix, and let a named person decide before anything in the source data changes.

A scorecard that clears this bar names every dimension checked, the rule it was checked against, the finding with a count and examples, a severity, and an explicit go / go-with-fixes / no-go verdict for the specific thing the data is about to feed.

Root cause — sizing, ruling out, then explaining

A metric moved and someone wants to know why before the meeting. The playbook gives you the four-step flow; mastery is resisting the pull toward a satisfying story before you’ve earned one.

• Size the move against a baseline before you chase a cause. “Down a lot” sends you hunting for a crisis that might not exist; “down 9% week-over-week, inside the normal ±8% swing” tells you there’s nothing to explain. Anchor every move to a baseline’s normal variation first — a real number of investigations dissolve right here, the moment someone checks whether the metric was ever actually outside its usual range.
• Rule out the data before you’re allowed to blame the business. This is the step almost every team skips under deadline pressure, and it’s the one that prevents the most expensive mistake on this page. A missing day, a tracking change, a schema edit, or a metric definition that quietly drifted since M1 can produce a move that looks identical to a real business shift. Check for missing dates, blank-rate jumps, schema changes, and — critically — whether the metric’s definition in metrics.md is still the one being computed. A confident “the business changed” that’s actually an artifact is the failure this whole module exists to prevent.
• Decompose by the dimension that actually carries the cause. A top-line move is a sum of segment moves. Break it down by the dimension most likely to explain it — channel, plan tier, account type, region — so you isolate what moved before you assert why. A drop concentrated in one segment points at a specific, checkable cause; a drop spread evenly across every segment points at something systemic, and those are different investigations with different next steps.
• State the confirming check, and don’t skip running it. Naming the most likely explanation is not the finish line — naming the single check that would confirm or kill it, and then actually running that check, is. A hypothesis that travels upward worded as a confirmed cause is a claim the company will act on; keep it provisional, in writing, until the confirming check has actually been run.

A root-cause writeup that clears this bar states the size of the move against its baseline, the data-artifact check and its result, the segment breakdown that localizes the cause, the leading hypothesis, and the one check that confirmed it.

Reconciliation is where the two gates meet

The clearest place quality and root cause meet is reconciliation — checking that two views of the same number agree. When a quality audit on a revenue table turns up a discrepancy against an independent total, you’re not just looking at a data-quality finding anymore; you’re looking at the start of a root-cause investigation, and the discipline from both playbooks applies at once: state the rule the two totals are supposed to satisfy (they should match, or match within a stated tolerance), then run the same rule-out-the-data-first step before you reach for a business explanation. Most reconciliation gaps are data artifacts — a mis-mapped join, a double-counted row, a timing mismatch between when two systems record the same event. A few are real, and finding one of those is exactly what root cause is for. This module’s worked example below is one of the real ones.

Your assignment

Run the two-gate discipline against one dataset and one anomaly — your own (recommended: this becomes the standing pre-flight check your team runs every time something matters) or the sample brand Mizan, the GCC bookkeeping SaaS whose Business Analyst, Maya Haddad, runs throughout this track. Everything you produce inherits the foundation files from M1 and the query discipline from M2; if you don’t have them yet, do Module 1 and Module 2 first. Open your data folder in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.

Module 3 deliverable — quality & root cause

Inherits from M1: dataset-profile.md + metrics.md
Inherits from M2: the join/query discipline (re-runnable, auditable queries)

1. data-quality-report.md   (one dataset, before it feeds something real)
   - the stated rule set: unique key, never-null columns, valid
     ranges/values, required foreign keys, freshness requirement
   - all six dimensions checked: completeness, validity, uniqueness,
     referential integrity, freshness, drift — each against its rule
   - every finding: count, example rows, severity (blocker / warning / note)
   - an explicit go / go-with-fixes / no-go verdict naming what the
     data is about to feed

2. root-cause.md   (one real or sample anomaly the audit surfaced,
   or any metric that moved)
   - the move sized against a trusted baseline, with the baseline's
     normal variation stated
   - the data-artifact check: missing dates, blank-rate jumps, schema
     changes, and a check against metrics.md that the definition didn't drift
   - a breakdown by the dimension that explains the move (not a guess
     at the dimension — shown against the baseline, segment by segment)
   - the leading hypothesis, the single confirming check, and that
     check's actual result — not left as "probably"

Bilingual teams: if the verdict or the root-cause finding goes to a
non-English-reading owner, author that summary in Arabic — the same
"author, don't translate" standard from M1, numbers staying Western.

The Foundation toolkit you installed in M1 already holds your CLAUDE.md and your dataset-profile.md / metrics.md templates. Build this module’s two files alongside them — the quality and root-cause habits are meant to run against the same folder, every time.

How it’s graded — the rubric

This is the part the free playbooks don’t have, and the part that makes the credential mean something. Your two deliverables are scored against five criteria. Each is meets / nearly / not yet — and a “nearly” on any one is a revise, not a pass.

Quality & root-cause rubric

1. The rules are stated, not implied      Every quality dimension is tested
                                          against an explicit rule (unique
                                          key, valid range, required FK,
                                          freshness bar) — not "looks fine."

2. All six dimensions are run            Completeness, validity, uniqueness,
                                          referential integrity, freshness,
                                          and drift are all present — not
                                          just the two cheap ones.

3. Severity makes the verdict honest     Every finding has a severity
                                          (blocker / warning / note) and the
                                          final verdict (go / go-with-fixes /
                                          no-go) is explicit and named to
                                          what the data is about to feed.

4. The data was ruled out before the     The root-cause writeup checks for
   business was blamed                   missing dates, blank-rate jumps,
                                          schema drift, and a metrics.md
                                          definition check — before naming
                                          a business cause.

5. The cause is confirmed, not asserted  The leading hypothesis names the
                                          one confirming check, and that
                                          check's actual result is shown —
                                          not left as a plausible guess.

The discipline is deliberately what a skeptical data lead would demand before a number reaches a board pack or an auditor’s question: an audit with no stated rules, or a root-cause story that skipped ruling out the data, fails quietly — discovered weeks later by someone re-deriving the number from scratch — so it has to be caught here.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample brand — your own doesn’t need to look like this, it needs to clear the same bar. This is Maya Haddad’s investigation, run the week before Mizan’s March numbers were due in the board pack — the same numbers feed the board-pack deliverable from the Finance & Ops track — and it ends somewhere Maya didn’t expect.

data-quality-report.md — subscriptions + revenue export, March 2026 (excerpt)

Stated rules (ratified with Nadia before testing):
  - subscription_id: unique, never null
  - account_id: must exist in customers table (referential integrity)
  - plan_tier: one of {Starter, Pro, Business}; billing_interval: monthly|annual
  - charge_amount: >= 0
  - data must cover through 2026-03-31, no missing days

Completeness         PASS    0 nulls on subscription_id, account_id, or
                              charge_amount. plan_tier null on 0.4% (4 rows,
                              new trial accounts not yet assigned — NOTE)

Validity              PASS    All charge_amount >= 0. All plan_tier and
                              billing_interval values within the allowed set.

Uniqueness             FAIL   14 duplicate subscription_id values found —
                              ALL 14 are annual-plan rows, all dated on or
                              after 2026-03-01. Each duplicate pair has the
                              same account_id, same plan, same amount, two
                              different charge timestamps both in early
                              March. BLOCKER — flagged below for root cause,
                              not deduped here (an audit surfaces, it
                              doesn't silently fix).

Referential integrity  PASS    Every account_id resolves to a row in
                              customers. 0 orphans.

Freshness               PASS   Covers through 2026-03-31. No missing days
                              (31/31 dates present).

Drift                   WARN   Row count +1.1% vs February, in line with
                              new-signup growth. But total March revenue
                              is AED 9,400 higher than the subscriptions
                              table alone implies for active accounts at
                              March's contracted rates — a reconciliation
                              gap, not explained by growth. NOTE: this is
                              the same direction and rough size as the 14
                              duplicate rows above; likely connected.

VERDICT: GO WITH FIXES. Blocker: the 14 duplicate subscription_id rows
must be resolved (likely double-charges, not legitimate re-subscriptions —
see root-cause.md) before March revenue is finalized for the board pack.
Warning: 4 trial accounts with null plan_tier — acceptable, expected for
mid-month trial signups. Safe to proceed to the board-pack reconciliation
once the blocker is resolved.

root-cause.md — the AED 9,400 MRR reconciliation gap, March 2026 (excerpt)

1. Size the move against a baseline
   March MRR per the subscriptions table (status='active', annualized/12):
   AED 474,800. March MRR per the independent finance reconciliation
   (Stripe payout total / 12 for annual, summed with monthly): AED
   484,200. Gap: AED 9,400 (2.0%). Baseline check: this reconciliation
   has matched within 0.3% every month since January — a 2.0% gap is
   well outside the normal variation. This is a real signal.

2. Rule out the data first
   - All 31 days of March present in both sources; no missing dates.
   - metrics.md MRR definition unchanged since M1 — checked against the
     dictionary, not just memory. Not a definition drift.
   - Schema: no new or renamed columns in the export this month.
   - BUT: the subscriptions table is missing exactly 14 charge events
     that the payment processor's log shows — these are the same 14
     duplicate subscription_id rows the quality audit flagged. The
     subscriptions table under-counts because it stores one row per
     subscription, while the processor charged it twice; the payout
     total (used for the independent reconciliation) reflects the real
     cash collected, including the duplicate charges.
   - This is NOT a tracking or schema artifact — it is a real billing
     event the subscriptions table structurally can't represent twice.
     Ruled out: pipeline bug. Confirmed: a real, double-charged event.

3. Break it down by dimension
   All 14 affected rows: annual-plan customers. 0 monthly-plan
   customers affected. All 14 charge timestamps: on or after
   2026-03-01. Zero double-charges before that date, on any plan.
   Concentrated entirely in one segment (annual, post-March-1) — not a
   broad, systemic gap. Per-customer impact: AED 300–1,200 (varies by
   plan tier), consistent with each being charged their plan price
   twice.

4. Hypothesis and the confirming check
   Leading hypothesis: the March 1 annual-renewal billing run double-
   fired for a subset of annual accounts — a retry or a duplicate batch
   job, not a customer-side or pricing-side cause (no monthly customers
   affected, no pricing change in the window).
   Confirming check: pulled the billing-run job log for 2026-03-01.
   Result: CONFIRMED — the annual-renewal batch ran twice within nine
   minutes due to a retry trigger that didn't check for an existing
   successful run. 14 annual accounts were charged in both passes.

CONCLUSION: the AED 9,400 MRR gap is fully explained — 11 of the 14
affected customers had not yet been refunded or corrected as of this
analysis; the other 3 were resolved earlier in March through unrelated
support contact. Effective unresolved impact: 11 customers, AED 300–1,200
each, all annual-plan, all dated on or after 2026-03-01.

NOTE FOR THE BOARD PACK: this is the SAME incident Mizan's Support team
identified independently this week via ticket triage — 11 annual-plan
customers, double-charged on or after 2026-03-01, traced to the same
March 1 billing run. Two teams, two completely different methods —
Support found it reading the ticket queue for a bug pattern; Data found
it reconciling MRR against an independent total during a routine
quality audit — landed on the identical 11 customers, the identical
trigger, the identical date boundary. That convergence is not a
coincidence; it's what a real, confirmed root cause looks like from two
directions at once, and it's exactly the kind of cross-check this
discipline is built to produce. Recommend: the board pack reports March
revenue net of the 11 unresolved duplicate charges, with a one-line note
that a billing-run fix and customer refunds are in progress.

What changed before this went to Finance — the discipline visible

  Quality audit FIRST.    Found 14 duplicate rows as a structural
                          uniqueness failure — before anyone asked
                          "why doesn't revenue match."

  Reconciliation SECOND.  The same audit's drift check caught the
                          AED 9,400 gap against an independent total —
                          the audit doing double duty as the trigger
                          for root cause.

  Root cause THIRD.       Ruled out a tracking/schema artifact FIRST,
                          only then localized to annual + post-March-1,
                          only then named and CONFIRMED the billing-run
                          retry — never reported as a guess.

  Cross-checked LAST.     Recognized the Support team's independently-
                          found bug as the same incident — two methods,
                          one truth — instead of two unexplained
                          findings sitting in two different tools.

What you’ve proven — and what’s next

Clear the rubric and you’ve proven something a one-off “looks fine” check never can: that your team can defend a number on demand — show the rules a dataset was tested against, the severities that earned a verdict, and a root cause that was sized, cleared of artifacts, localized, and confirmed before it shipped. That’s the Quality & Root-Cause stage of “Certified Data & Analysts with Claude.”

From here the track turns a trustworthy, defensible number into a full analytics operation, each module assessed the same way:

• Module 4 — experiments & charts: reading an A/B test honestly under pressure to ship, and turning a CSV into a chart that survives a second look.
• Module 5 — the reporting system: building the recurring report that comes out the same way every month, then the capstone — Insight-in-a-Box, the full investigation taken from raw export to certificate.

First, make the discipline reusable. The quality rule set and the root-cause checklist you just built are the permanent artifacts that turn one careful Tuesday into the standard your team runs every time a number matters. If you’re rolling this across a team, the operating guide is the PROFILE FIRST, RECONCILE, and DATA SAFETY layer that belongs underneath the whole discipline.