This training is not about statistics. It’s about the specific skill of directing AI well enough that it makes your analytic work better instead of murkier — and knowing exactly where the line is that it shouldn’t cross.

Who this is for

Consultants at Facente with intermediate-to-advanced quantitative skills — comfortable in R, Excel, or similar tools, and fluent in the underlying statistics — who want to use Claude well as part of that work. Nothing here will teach you what a confidence interval is. Everything here is about the conversation you have with Claude around your analysis.

How this works

Read, watch the one embedded video, and do the practice prompts as you go — most are short. Four points in the training are marked as checkpoints: you’ll post a small piece of real work to #_facentrain, and Shelley will reply there with feedback or answer questions. You can move through this straight through, or jump to whichever module is most relevant using the menu on the left.

By the end, you’ll be able to

• 01Explain what Claude can and can’t reliably do with quantitative data, and why that distinction matters for your work.
• 02Handle client data safely in a Claude conversation — without ever uploading a raw dataset.
• 03Structure a prompt that produces a genuinely useful analysis plan, not just a plausible-sounding one.
• 04Use Claude as a debugging partner and a stats tutor — not just a code vending machine.
• 05Use Claude to pressure-test your framing, equity lens, and limitations before a report goes out the door.

1.1  What Claude is actually doing

Claude doesn’t “know” your data, “run” your regression, or “look up” a fact the way a colleague would — unless it’s actually using a tool, like web search or code execution, to do that specific thing. Underneath, at every step, it’s predicting the most plausible next stretch of text given everything you and it have said so far. That’s the whole mechanism. The well-organized bullet points, the confident tone, the apparent understanding — all of that is a byproduct of very good next-word prediction, not a separate layer of comprehension sitting on top of it.

That has a direct, practical consequence for quant work: Claude is genuinely strong at pattern-based reasoning — spotting what’s odd about a regression result, generating analysis options you hadn’t considered, restructuring a dense paragraph. It’s much less trustworthy the moment a task secretly depends on doing arithmetic on data it can’t actually see, or recalling a specific fact rather than a general pattern. Knowing which situation you’re in is most of the skill covered in this training.

For the underlying mechanics — well worth the nine minutes if you want the real model, not a metaphor:

“Large Language Models explained briefly,” 3Blue1Brown (~9 min, free, YouTube).

1.2  What’s different about this vs. Googling or asking a colleague

• It reflects the patterns in its training data — which has its own blind spots and dominant assumptions, the same caution you’d apply to any single source. It won’t volunteer where it might be biased on a given topic, but it’s genuinely good at surfacing that if you ask directly: “What assumptions am I making here that you’d push back on?”
• Long, meandering conversations degrade. If Claude starts repeating itself, contradicting something you already told it, or missing context you gave it earlier, that’s your signal to start a fresh conversation rather than push through the same thread. It’s less that it “runs out of memory” and more that a long, unfocused thread makes it harder for the model to weight what’s actually relevant right now.
• It can hold a lot in one conversation — a full codebook, long interview transcripts, several documents at once — far more than older tools could. That’s genuinely useful. It is not, however, a reason to paste in more than you need, especially where client data is involved. More on exactly where that line sits in Module 2.

1.3  A few things worth knowing about Claude specifically

• Projects. Claude.ai has a “Projects” feature — a way to store a client’s codebook, style guide, or background documents once, so every new conversation about that project starts with that shared context instead of you re-explaining it each time.
• Tools, used directly. Claude can search the web when it’s useful, and — depending on what’s turned on in your workspace — execute code or produce files. Ask for what you actually want rather than working around a limitation Claude may not even have anymore.
• Facente’s Team plan. By default, Anthropic does not use conversations from commercial plans like ours to train its models (confirm current settings under your workspace’s Data & Privacy settings if you want to check). That’s a genuinely different default than some consumer AI tools. It does not change the rule in Module 2 about never uploading raw client data — that rule is about confidentiality and security norms, not just model training.

Quick self-check

2.1  Why this isn’t optional in our work

Facente Consulting handles HIV, HCV, STI, and substance-use treatment data — often under data use agreements, IRB conditions, or confidentiality obligations that existed long before any AI tool did. Those obligations don’t change because the tool got smarter. The rule in this module applies regardless of which AI tool you’re using, and regardless of how good its privacy settings are.

2.2  What Claude’s Team plan actually does with your data

• By default, Anthropic does not use commercial-plan conversations (including Team plans like ours) to train its models. That’s a real, verifiable default — not marketing language — and it’s a meaningfully different posture than some consumer AI products.
• That said, your conversations are still stored on Anthropic’s servers, and a Team account is not a substitute for a properly executed data use or business associate agreement. Treat it the way you’d treat any external SaaS tool without a signed data agreement in place — because unless one exists for our account, that’s exactly what it is.

2.3  The rule: describe your data, don’t upload your data

Never upload a raw dataset with row-level records — especially anything with participant identifiers — to any AI tool, including Claude. Instead, describe it well enough that Claude can reason about its structure without ever seeing a real person’s record.

Spot the difference

Two ways someone might start a prompt about the same project:

A: “Here’s our client roster spreadsheet [attached] — can you tell me which demographics are underrepresented in MAT access?”

B: “I have a dataset of N=[x] treatment episodes with these variables: [list, with types]. Here’s the summary statistics for each [attached, no row-level data]. Which demographics appear underrepresented in MAT access based on this summary, and what analysis would confirm it?”

Only B is safe to send — and it also happens to produce a more useful answer, because it forces you to hand Claude structure instead of hoping it infers the right thing from a raw file.

3.1  Four ingredients of a prompt that actually plans an analysis

1. What you’re working with — R, Excel, SPSS, and the dataset itself (described per Module 2)
2. What you want Claude to do — suggest analyses? critique a plan you already have? both?
3. The scope of this specific question — not “analyze my data,” but the actual research question at hand
4. What you want the output to sound like, and for whom — a technical peer-review memo reads nothing like an advocacy brief

Giving Claude a role — “Act as a PhD epidemiologist,” “act as a skeptical program officer” — isn’t decoration. It’s telling the model which register and which body of pattern to draw from. A biostatistician’s caveats look different from a policy advocate’s framing, and naming the role gets you closer to the one you actually want.

3.2  Pressure-test the plan before you run it

Three reusable prompts, each catching a different kind of failure:

Keep these three almost exactly as written in your own prompt bank (Module 6 has a starter one). They’re reusable as-is across nearly any project.

4.1  The core prompt shape for code

The “explain the logic” part matters even when you already know the right answer. It’s your check that Claude’s reasoning is actually sound rather than just plausible-looking — the same instinct you’d apply to a junior colleague’s first draft.

4.2  Real example: the ggplot legend bug

4.3  Real example: stats-tutor mode, not just code

4.4  The same structure works outside of code

The fastest way to undermine solid quantitative work is to report it in a way that blames people for what a system did to them — or to let a real limitation surface for the first time in a reviewer’s comments instead of your own draft. Claude is genuinely useful for catching both, if you ask directly. It won’t volunteer this on its own.

5.1  Real example: the equity-lens review

5.2  Real example: the limitations review

5.3  Two more worth keeping

6.1  Build a living prompt bank

The fastest way to lose the value of this training is to reinvent these prompts from scratch every time. Keep a running doc — even the checkpoint drafts from this training are a start — with the prompts that actually worked for you.

6.2  Wrap-up

Four checkpoints, whenever you reach them: data description, analysis-planning prompt, a real debugging pass, and the framing/limitations capstone — all posted to #_facentrain. I review async and reply there; no need to wait for a live session.

None of this replaces your judgment. It just means the time you spend with Claude produces something worth trusting, instead of something that merely sounds finished.