You finished the Foundation module with three documents: a dataset-profile.md, a metrics.md, and an analysis-brief.md for one real request. This toolkit makes them infrastructure. A dictionary you wrote once helps you once; a dictionary your team queries from — that Claude reads on every task — helps every report, forever.
Everything here is copy-able. Replace the Mizan placeholders (the GCC bookkeeping brand whose Business Analyst, Maya Haddad, runs through the module) with your own, save the files in the folder your team works in, and open it in Claude Desktop. From then on, every analysis task in that folder starts from your real columns, your real metric definitions, and your real scoping habits — instead of each analyst’s guess.
The whole pack is four files and a handful of prompts. That’s the point — a foundation small enough to actually get queried beats a beautiful one that lives in a doc nobody opens. Keep raw customer data out of it: this folder holds your team’s definitions and conventions, never a live export full of names and emails.
The data CLAUDE.md
This is the standing context Claude reads automatically when it opens your project folder, so nobody has to re-explain a metric or a source table every chat. Keep it short and current — it points at the foundation docs rather than repeating them.
# CLAUDE.md — [Team name] data & analytics
## What we do
[Team name] answers data questions for [Company] — [one-line product
summary]. Our main sources are [list: e.g. "the `subscriptions` and
`customers` tables, weekly CSV exports from the marketing tool"].
## The three source-of-truth files — read these first
- metrics.md → WHAT our numbers mean (exact logic, owner, edge
cases for every metric we report)
- dataset-profile.md → WHAT a given source actually contains (per file,
re-profiled whenever the schema changes)
- analysis-brief.md → WHAT this specific request is actually asking
(decision, precise question, scope) — one per
active request, not a single standing file
Always check metrics.md before computing a metric that already has a
definition. If a request needs a metric that isn't in the dictionary yet,
propose an addition — don't invent a one-off definition in a chat.
## The golden rule
Profile before you query. Reconcile before you report. Every total that
leaves this folder is checked against a second source — a row count, a
prior report, a finance figure — before a stakeholder sees it. A number
you can't reconcile is a number you can't defend.
## Verification non-negotiables
- State the row count and how you verified it, every time you open a
new file.
- Read real values for every column before trusting what its name implies.
- Name the blank rate and duplicate count for any file you build a total on.
- Never report a number without saying which query or file it came from.
## DATA SAFETY — non-negotiable
Customer-identifying data — names, emails, account IDs not already
aggregated — stays in this workspace. Claude reads it to compute
aggregates and patterns; it is never asked to export raw rows, paste
identifiable records into a shared doc, or process PII outside this
folder. Charts and reports leave this folder only in aggregate form.
## What's safe in this folder
- Safe: metrics.md, dataset-profile.md (column-level descriptions, not raw
rows), aggregated query results, anonymized samples, chart images.
- Never here: raw customer exports with names/emails, full ticket or
billing records, anything that identifies one specific person. Tell me
if a file looks like it has them before we use it.On Desktop you create and edit this in the file pane — no commands. Anthropic’s docs call the “Ask permissions” mode the one recommended for new users; leave it on, and the first time Claude reads a data file you’ll approve it in the prompt.
The dataset-profile.md template
The interview every new file gets before you trust a total built on it. The “checked against values” discipline is what separates this from a glance at the column headers.
# dataset-profile.md — [file name]
## Row count
[N] rows. Verified against: [the export tool's own count / a stakeholder's
stated expectation / last period's count ± a sane delta]. State the match
or the discrepancy explicitly — don't skip this line.
## Columns
[column_name]
Meaning: [what it actually contains, checked against 20–30 sampled
real values — not assumed from the header]
Blanks: [N% blank, or "none"] — [if blank, name what a spot-check of
the blank rows suggests, and how you'll handle them downstream]
Watch for: [anything that surprised you — a column that lies, a
timestamp that isn't what it claims to be, values outside the
expected range]
[Repeat for every column. The "watch for" line is the highest-value
line in the whole document — it's the catch that prevents a bad chart.]
## Date range
[start] to [end]. Confirmed against: [the export filter used / a known
event that should be in range].
## Duplicates
[N] exact-duplicate rows found ([describe the match: same key + same
timestamp, etc.]). [N] near-duplicates (same key, different timestamp —
state whether this is expected, e.g. an update history, or a defect).
Decision: [dropped before reporting / kept and flagged / needs the
source-system owner to confirm which is correct].
## What this file is safe to answer, and what it isn't
[One or two sentences: given the above, what can you confidently build
from this file, and what would need a different or cleaner source first.]The metrics.md template
The dictionary every query, chart, and report cites. The “logic” line is the discipline — if it can’t become a query without a follow-up question, it isn’t done yet.
# metrics.md — [Team name]
## [METRIC NAME]
Meaning: [one plain-English sentence a non-analyst would understand]
Logic: [the exact filter/formula/SQL-shape — specific enough that a
stranger could write the query from this line alone]
Owner: [named person or named function — who approves changes to this
definition]
Edge cases:
- [a real boundary case and how it resolves — not "use judgment"]
- [a second real boundary case and how it resolves]
Last reviewed: [date] — bump this and note what changed whenever the
logic is revised. Old reports stay correct for the period they covered;
new reports use the current definition.
[Repeat per metric. Start with the 4–6 metrics that appear in your most
recurring report — the dictionary earns its keep fastest there.]The analysis-brief.md template
One brief per active request — this is not a standing document, it’s a template you fill out fresh every time someone asks for an analysis. The “out of scope” section is what prevents the most common kind of rework.
# analysis-brief.md — [the request, in 5 words or fewer]
Original request (verbatim):
"[paste the actual Slack message / email / meeting line — don't
paraphrase, you want to see exactly what's ambiguous]"
Decision this informs: [what will someone actually DO differently
depending on the answer — not the question itself]
Precise question: [the request translated into metrics.md vocabulary —
name the exact metric(s), not a restatement of their words]
Sources: [the table(s) or file(s) this will be built from]
Segments: [how the answer should be broken down, if at all]
Out of scope for this round:
- [something a reasonable person might assume is included, named
explicitly as excluded, with a one-line reason]
- [a second exclusion, if there is one]
Confirmed scope with requester: [yes/no — confirm before building
anything beyond a quick first look]The saved-prompt library (Foundation)
The recurring foundation jobs, as prompts you reuse. Paste them in the chat with the right files open; on the Terminal & Automation track these become slash commands so they’re one keystroke, but you need none of that to use them today.
Profile a new file
"Read [file name] from this folder. Tell me: the row count and how I
could verify it against another source, what every column actually
means based on real sampled values (not just the header), the real
date range, the blank rate per column, and any exact or near-duplicate
rows. Flag anything that looks like it doesn't match what its column
name implies."
Draft or update a metric definition
"Read metrics.md. We need a definition for: [metric name, e.g. 'trial-
to-paid conversion rate']. Propose: a one-sentence plain meaning, the
exact logic as a filter/formula, and 2-3 edge cases with how each
should resolve. Flag if this overlaps with or duplicates an existing
metric in the file."
Turn a vague request into a brief
"Here's a request I just got: [paste it verbatim]. Using metrics.md as
the vocabulary, draft an analysis-brief.md: what decision this likely
informs, the precise question translated into our metric names, the
sources and segments, and at least one thing a reasonable person might
assume is in scope that we should explicitly exclude this round."
Reconcile a number before it ships
"Here's a total I'm about to report: [paste the number and how it was
computed]. Check it against [a second source / a known total / last
period's figure]. Tell me if it reconciles, and if not, walk through
the most likely reasons for the gap (filter mismatch, date boundary,
duplicate rows, a join that dropped or duplicated records)."
Pressure-test a metric definition for edge cases
"Read this metric definition: [paste it]. Find 3 real-world situations
this logic might handle wrong or ambiguously — a customer who does
something unusual, a timing edge case, a status that doesn't cleanly
fit. For each, tell me what the current logic would compute and
whether that's actually the right answer."Installing it (Desktop, no setup)
- Save the four files —
CLAUDE.md,dataset-profile.md(one per source you query regularly),metrics.md,analysis-brief.md(template, filled fresh per request) — in the folder your team works in. - Open that folder in Claude Desktop and approve the read in the “Ask permissions” prompt.
- Start any task by opening the relevant docs; the prompts above do the rest.
That’s the whole install. The foundation you built in the module is now shared infrastructure — and Module 2 of the track extends this same pack with the query and join engine that builds on it. If you’re standing this up across a team rather than for yourself, read the operating guide for the data-safety and verification layer that belongs underneath the whole system.