Data Foundation: the dataset, the dictionary & the brief every analysis inherits

Your team already has the dataset-profile, metrics-dictionary, and analysis-brief playbooks — the worked recipes for interviewing a file, defining a metric, and scoping a request, step by step. This module is the layer above the recipe. It’s where you master the three things every later query, chart, and readout inherits — what your data actually contains, what your numbers actually mean, and what question you’re actually answering — build them for real, and prove, against a rubric, that you can.

It’s Module 1 of the certifiable Data & Analysts track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.

Every number your team reports — every dashboard, every query result, every stakeholder readout — is a withdrawal from three accounts: what the data actually contains, what the metric actually means, and what question you’re actually answering. Most teams never fund those accounts, so every analysis reprofiles blind, recomputes “active” a new way, and answers what was asked instead of what was meant. The foundation is the hour where you fund all three once, and it’s the highest-leverage hour in the whole track.

Why the foundation is the highest-leverage hour you’ll spend

Analysis fails quietly, not loudly. Nobody ships a report that says “Revenue: undefined.” They ship a report that says “Revenue: AED 474,800” — confident, formatted, on time — built on a column nobody checked, against a definition nobody wrote down, answering a question nobody actually asked. The chart launders the uncertainty: once a number is in a slide, nobody re-derives it.

Two failure modes account for nearly every bad number that reaches a stakeholder. The first is the blind analysis — querying a file you’ve never opened, trusting that status means what it sounds like, that the date range covers what you assumed, that there’s one row per customer instead of one per renewal. A bad assumption baked in at the start poisons everything built on top, and it’s invisible in the output because the output still looks like a normal number. The second is the drifting definition — two analysts pull “active users,” get two different answers, and both are right, because “active” was never written down anywhere both of them could read it. At small scale that’s an awkward meeting. At enterprise scale it’s a credibility leak: the board deck and the ops dashboard disagree, and the team spends the meeting reconciling definitions instead of finding insight.

Three things fix both failure modes before a query is ever written. A profiled dataset means you know exactly what you’re working with — row count, what every column means, where it’s dirty — before you trust a single total built on it. A metric dictionary means “active,” “churn,” and “revenue” each have one canonical definition with an owner, so two analysts who pull the same metric get the same number. An analysis brief means the question is pinned down — the decision it informs, the precise ask, what’s out of scope — before anyone touches a query, so you build the right analysis once instead of three times. Build these three and every later module inherits them: the query engine in M2 trusts the columns because M1 already profiled them; the readouts in M4 cite “churn” with confidence because M1 already defined it; the recurring report in M5 doesn’t re-litigate scope every month because M1’s brief already drew the line.

Skip this module and Claude just helps your team query faster against data nobody verified, answering definitions nobody agreed on. That’s worse, not better — a confident wrong number ships faster than an honest “I’m not sure yet.” Fund the three accounts first and every analysis downstream gets sharper and safer for free.

Profiling — the judgment the recipe can’t teach

The playbook gives you the steps: open the file, ask Claude to describe it back. Mastery is the judgment inside that step — the calls that separate a profile that actually catches dirt from one that just confirms what you already assumed.

• The row count is your contract — verify it, don’t accept it. Before you build anything, the row count Claude reports needs to match a number you can independently check: the export tool’s own count, the number a stakeholder told you to expect, last month’s count plus or minus a sane delta. A profile that reports “8,432 rows” and stops there has told you nothing; a profile that reports “8,432 rows, and the export tool’s dashboard also shows 8,432” has told you the file isn’t truncated. The gap between those two sentences is the entire value of profiling.
• The column that lies is the one that gets you. Every dataset has at least one column whose name promises something its values don’t deliver — a status field with a value that means something different than the obvious reading, a plan column that records what was requested rather than what’s active, a date that’s a created-at timestamp masquerading as an event date. Read a sample of actual values for every column before you trust the header. The header is a hypothesis; the values are the evidence.
• Blanks are a finding, not noise to filter out. A column that’s 12% blank is not “mostly fine” — it’s a fact about your data collection that changes what you can responsibly claim. If you build a breakdown by that column and silently drop the blanks, you’ve quietly excluded over a tenth of your rows from the answer without telling anyone. State the blank rate explicitly, and decide on purpose whether blanks get their own bucket, get excluded with a stated caveat, or block the analysis until the source system is fixed.
• Duplicates hide in plausible-looking rows. A handful of exact-duplicate rows — the same event logged twice by a retry, the same record exported in two batches — will quietly inflate any count built on the file. Check for exact duplicates and near-duplicates (same key, different timestamp) before you report a total, not after a stakeholder asks why the number looks high.

A profile that clears this bar tells you the row count and how you verified it, what every column actually means (checked against values, not assumed from the header), the real date range, the blank rate per column, and the duplicate count — before you’ve asked a single analysis question.

The metric dictionary — definitions that don’t drift

A metric dictionary is not a glossary of nice-sounding phrases. It’s the document that ends the argument before it starts, and the discipline that makes it work is precision, not consensus.

• Logic, not vibes. “Active means the customer used the product recently” is not a definition — it’s a vibe. “Active means at least one billable action in the trailing 30 days, computed from the events table filtered to event_type IN (billable_list)” is a definition. Anyone who reads it can reproduce your number without asking you a follow-up question. If a definition can’t be turned into a query by someone who’s never spoken to you, it isn’t precise enough yet.
• One metric, one owner. Every metric gets exactly one named owner — the person who approves changes to its definition. Without an owner, a well-meaning analyst “improves” the churn definition mid-quarter and last month’s number stops being comparable to this month’s, silently. The owner isn’t a gatekeeper guarding a secret; they’re the person accountable for the metric meaning the same thing every time it’s reported.
• Edge cases are where the fights actually happen. Nobody disagrees about whether an obviously-active customer is active. The argument is always about the edge: does a customer on a free trial count? Does a paused-but-not-cancelled subscription count as churned? Does a refunded transaction still count in revenue for the month it happened? Write down every edge case you can think of and how it resolves — that’s the section that actually prevents the next argument, not the headline definition.
• The dictionary doesn’t ask you to agree on what’s right — it asks you to write down what’s decided. Teams stall metric dictionaries waiting for the “correct” definition of churn. There usually isn’t one universally correct definition; there’s a decision your team needs to make once and hold to. Pick a defensible logic, name the owner, write the edge cases, move on. A documented, slightly-imperfect definition beats an undocumented argument every time it’s reported.

The analysis brief — turning a vague ask into an answerable one

“Can you look into churn?” is not a question you can build a query against. The brief is the twenty minutes that turns a vague ask into something you can actually answer — and skipping it is the single most common cause of analysis rework.

• The decision is the real spec, not the question as asked. A stakeholder rarely states the decision their question feeds — they state the question. “What’s our churn rate?” might be feeding a board update, a save-flow prioritization call, or pure curiosity, and those three decisions want completely different analyses: a board update wants a trend with context; a prioritization call wants churn broken down by segment with a dollar amount attached; curiosity wants one number. Ask what the answer will be used to decide before you build anything — it’s the single highest-leverage question in the brief.
• Out of scope is the most valuable line you’ll write. A brief that lists what you’ll cover but not what you won’t invites scope creep the moment you share a draft — “while you’re in there, can you also break it down by…” Naming what’s explicitly excluded for this round, and why, gives the stakeholder a clean place to push back before you’ve built anything, instead of after.
• Translate the ask — don’t just relay it. A stakeholder writes in their own vocabulary, which is often imprecise on purpose; your job is to translate it into the metrics and sources from your dictionary, not transcribe their words into a query. “Look into churn” becomes “monthly logo churn rate, as defined in metrics.md, broken down by plan tier and country, for the trailing two quarters.” If the translation changes the meaning of what they asked, that’s not overreach — that’s the brief doing its job.

The Arabic standard — what a bilingual readout actually requires

For a team that reports to bilingual leadership, this is not a translation pass applied to the finished slide. It’s a standard the brief sets from the start, because the failure mode is specific: an English readout and an Arabic readout that quietly cite different numbers, because they were built from two separate passes at different times.

• Author the narrative in Arabic; don’t translate the English narrative. An Arabic readout that was written in English and run through translation carries English sentence structure and reads like a foreign report. Write the Arabic narrative from the same reconciled numbers, in the register a GCC leadership team actually reads — direct, numbers up front, no padding — the same way you’d write the English version from scratch.
• Numbers stay Western numerals; only the prose is Arabic. 474,800 stays 474,800 in an Arabic readout — never converted to Eastern Arabic-Indic digits — and currency stays AED. This is a convention, not a preference, and getting it backwards is the single most common tell that a readout was machine-translated rather than authored.
• Both languages cite one reconciled appendix — never two. The discipline that prevents English and Arabic from quietly disagreeing on a figure is structural: build one reconciled numbers appendix, and have both narratives reference it rather than each carrying its own copy of the totals. If a number changes, it changes once, in one place, and both languages update together.

Your assignment

Build the three foundation documents for one dataset and one real request — your own (recommended: the output becomes infrastructure your whole team queries from) or the sample brand Mizan, a GCC bookkeeping SaaS whose Business Analyst, Maya Haddad, runs throughout this track. Open a folder with your raw export in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.

Module 1 deliverable — the data foundation

1. dataset-profile.md  (one page, for one real file)
   - verified row count (and how it was checked against a second source)
   - every column explained in plain English, checked against sample
     values — not assumed from the header
   - the real date range and how it was confirmed
   - blank rate per column that has any blanks
   - duplicate check: exact and near-duplicate count
   - at least one "the column that lies" catch, if the file has one

2. metrics.md  (one page, 4–6 metrics your team actually reports)
   - each metric: plain-English meaning, exact logic (filter/formula
     specific enough to turn into a query without a follow-up question)
   - a named owner per metric
   - 2–3 edge cases per metric and how each resolves

3. analysis-brief.md  (one page, for one real stakeholder request)
   - the decision the answer will inform — not just the question asked
   - the precise question, translated into metrics.md vocabulary
   - the exact sources and segments
   - what's explicitly out of scope for this round, and why

Bilingual teams: note where this brief's eventual readout will need an
Arabic narrative, citing the same reconciled appendix as the English one.

The Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank file.

How it’s graded — the rubric

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

Foundation rubric

1. Profile is honest and complete   The row count is verified against a
                                    second source, not just stated. Every
                                    column is explained from real values,
                                    not the header. Blank rate and
                                    duplicate count are both named.

2. Metrics are precise, not vibes  Every definition is specific enough
                                    that a stranger could turn it into a
                                    query without asking a follow-up
                                    question. Each has a named owner.

3. Edge cases are written down     At least 2 real edge cases per metric,
                                    each with a stated resolution — not
                                    left as "use judgment."

4. The brief is genuinely          The decision it informs is named. The
   answerable                      question is translated into metrics.md
                                    vocabulary. Scope is explicit, with at
                                    least one item named out of scope.

5. Bilingual readout standard      Both languages would cite one reconciled
   is right (bilingual teams)      appendix. Numbers stay Western numerals;
                                    the Arabic narrative is authored, not a
                                    translation of the English draft.

The discipline is deliberately what a skeptical analytics lead would demand: a profile that’s superficial, a metric that’s vague, or a brief that’s still vague after the brief fails quietly on every analysis built on top of it — 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. These are Maya Haddad’s documents, Mizan’s Business Analyst, built the week leadership asked for a churn read.

dataset-profile.md — signups.csv (excerpt)

Row count: 8,432 rows.
Verified against: the marketing tool's own export summary, which also
reports 8,432 signups for the period — counts match.

Columns (checked against 30 sampled values each, not assumed from header):
  signup_date  Date the trial signup form was submitted. Confirmed this is
               a created-at timestamp, not an activation date — 6% of rows
               have a signup_date with no corresponding account creation,
               meaning the form was submitted but the account was never
               provisioned. Flag this for the brief: "signups" in this
               file means form submissions, not provisioned trials.
  source       Marketing channel attribution. BLANK ON 12% OF ROWS — these
               are signups with no UTM tag, mostly direct/typed-URL traffic
               based on a manual spot-check of 20 blank rows. Do not drop
               these from channel breakdowns; bucket them as "untagged."
  country      ISO country code. No blanks. 84% UAE/Saudi/Qatar/Kuwait —
               consistent with the GCC customer base.
  plan         THE COLUMN THAT LIES: this records the trial plan tier the
               person REQUESTED at signup, not their current plan if they
               converted. 340 rows show a "Pro" trial request from accounts
               that are actually on "Starter" today — they downgraded
               post-trial. Do not use this column for current-plan
               reporting; join to the subscriptions table instead.

Date range: 2026-03-01 to 2026-03-13. Confirmed against the export filter
used to pull the file (date picker screenshot retained).

Duplicates: 3 exact-duplicate rows found (same signup_date + email hash +
source), consistent with a known double-submit bug on the trial form.
Dropped before any count is reported. 0 near-duplicates beyond these 3.

metrics.md — Mizan (excerpt, 3 of 5)

ACTIVE CUSTOMERS
  Meaning:  A paying account with a subscription in good standing.
  Logic:    COUNT(DISTINCT account_id) FROM subscriptions
            WHERE status = 'active' AND plan != 'trial'
  Owner:    Maya Haddad (Business Analyst)
  Edge cases:
    - Paused (not cancelled) subscriptions: EXCLUDED from active count,
      INCLUDED in "at-risk" count. A pause is a churn signal, not a no-op.
    - Accounts mid-downgrade (old plan ends, new plan starts same day):
      counted once, under the new plan, not double-counted across both.

MONTHLY LOGO CHURN
  Meaning:  Share of active customers at the start of the month who
            cancelled by month end. Logo churn, not revenue churn — a
            cancelled AED 49/mo account and a cancelled AED 249/mo
            account count the same.
  Logic:    cancelled_this_month / active_at_month_start
  Owner:    Nadia Al-Sayed (Head of Customer Operations)
  Edge cases:
    - A customer who cancels and resubscribes within the same month:
      counted as churned. Resubscribing later doesn't retroactively undo it.
    - Involuntary churn (failed payment, no retry success after 3 attempts):
      INCLUDED in churn, tagged separately as "payment churn" — different
      fix (dunning) than voluntary churn (different product/CS fix).

MRR (Monthly Recurring Revenue)
  Meaning:  Normalized monthly subscription revenue across all active
            accounts, as of the last day of the month.
  Logic:    SUM(plan_price / billing_interval_months) WHERE status='active'
  Owner:    Finance (reconciled monthly against the general ledger close)
  Edge cases:
    - Annual plans: divided by 12, not counted as a lump sum in the month
      they're billed — this is what makes MRR comparable month to month.
    - Mid-month plan changes: prorated amount used, not the new plan's
      full price, to avoid overstating the month it changed in.

analysis-brief.md — "Can you build us a churn dashboard?" (Nadia Al-Sayed)

Original request (verbatim, from Slack):
  "Hey — can someone build us a churn dashboard? Want to keep an eye on
  this going into Q2."

Decision this informs: Whether Customer Operations launches a save-flow
  (proactive outreach to at-risk accounts) in Q2, and which segment it
  targets first. Not a board metric — an operational prioritization call.

Precise question: What is monthly logo churn (per metrics.md), trended
  over the trailing two quarters, broken down by plan tier and country —
  and which segment has both the highest churn rate AND enough volume to
  justify a dedicated save-flow?

Sources: subscriptions table (status, plan, cancelled_at), customers
  table (country) — joined on account_id.

Segments: plan tier (Starter / Pro / Business), country (UAE / Saudi /
  Qatar / Kuwait / other).

Out of scope for this round:
  - Revenue churn and net revenue retention — logo churn only, this round.
    (Revenue churn is the natural M2 follow-up once this ships.)
  - A live, self-refreshing dashboard — v1 is a static monthly readout.
    A real dashboard is an M5 (the analytics system) deliverable.
  - Root-causing WHY any one segment churns — this brief answers WHERE
    to look, not why; that's a separate root-cause pass once we have
    the segment.

Maya confirmed this scope with Nadia before building anything — the
"not root-cause, not revenue churn, not a live dashboard" line is what
kept this a two-day brief instead of a two-week dashboard project.

What you’ve proven — and what’s next

Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade data foundation and demonstrated the judgment behind it. That’s the Foundation stage of “Certified Data & Analysts with Claude.”

From here the track turns the foundation into a working analytics operation, each module assessed the same way:

• Module 2 — the query & join engine: writing queries a stranger could audit, and turning two messy files into one dataset you can actually build a report on.
• Module 3 — quality & root cause: auditing a dataset before it feeds something that matters, and finding out why a number moved without guessing.
• 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 what you built reusable. Grab the Foundation toolkit — the data CLAUDE.md and the three templates that turn the documents you just wrote into files your whole team queries against on day one. And if you’re rolling this across a team, the operating guide is the data-safety and verification layer that goes underneath all of it.