Read the study before the software

“Did the program help?” is not one statistical question. AURORA-30 is the wholly synthetic teaching cohort and dataset used to expose that ambiguity: 30 fictional records, with no real patients, institutions, interventions, or outcomes; it does not constitute clinical evidence. This diagnostic shows what to review before software enters the reasoning.

The opening conflict: one table, three questions

The AURORA-30 table makes three routes plausible:

• Day 30 between groups: compare the groups at the end of follow-up.
• Before and after in the same person: estimate within-person change from baseline.
• Change between groups: compare the groups’ mean changes from baseline.

All three can be mathematically correct. They are not interchangeable: each targets a different quantity, uses dependence differently, and supports a different interpretation. Rigor begins by naming which question the result must answer and preserving that choice so another analyst can inspect it.

The trap: treating software fluency as statistical readiness

Someone can run a t test and still compare the wrong unit. Another learner may never have opened Python yet correctly recognize paired measurements. The second learner has the stronger foundation. Programming is a delivery mechanism; design and measurement determine what the numbers mean.

Eight readiness signals

Choose one response for each signal. There is no score or pass mark: “review” simply adds the matching repair to your route. The diagnostic works without a server and sends no response anywhere.

Worked example: meet AURORA-30

AURORA-30 is a fictional methods-training cohort with 30 synthetic participant records. It contains a baseline score, a day-30 score, an assigned follow-up workflow, a site, a time-to-event field, a synthetic reference classification, and two reader ratings. It is deliberately small enough to inspect and rich enough to support the full dossier. It is not evidence about a real intervention.

First run: start in the lab folder

Find the course folder that contains START_HERE.md, open a terminal there, and copy one runtime path below. Programming experience is not required. The first command fixes the working directory; the second checks the runtime; the third runs the supplied synthetic plan.

# From the course folder that contains START_HERE.md:
cd labs/analysis-plan-contract
python --version
python analysis_plan_contract.py --input samples/aurora30_plan.json --lang en --format text
python analysis_plan_contract.py --input samples/aurora30_plan.json --lang pt --format text

# Alternative base R path from the same lab folder:
Rscript --version
Rscript analysis_plan_contract.R --input samples/aurora30_plan.json --lang en --format text
Rscript analysis_plan_contract.R --input samples/aurora30_plan.json --lang pt --format text

# Windows PowerShell — read-only discovery in common installation roots
Get-ChildItem -LiteralPath 'C:\Program Files\R','C:\Program Files (x86)\R' `
  -Filter Rscript.exe -File -Recurse -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty FullName

# If a path is returned, invoke that exact discovered file:
& '<discovered absolute path to Rscript.exe>' --version

If discovery finds Rscript.exe, use that absolute path for the R commands or add its containing bin folder to your Windows PATH. If both checks return nothing, continue with Python; install R only if you want the second runtime and have confirmed it is absent.

Observable adaptation: predict, run, inspect

Keep the versioned sample untouched. From the analysis-plan-contract folder, make a learner-owned copy with the command for your shell:

# Windows PowerShell
Copy-Item -LiteralPath 'samples/aurora30_plan.json' -Destination 'my_aurora30_plan.json'

# macOS/Linux shell
cp -- samples/aurora30_plan.json my_aurora30_plan.json

1. Open my_aurora30_plan.json in a text editor. Change the safe metadata field "version": "1.0" to "version": "1.0-practice". Predict the first-line token, then run python analysis_plan_contract.py --input my_aurora30_plan.json --lang en --format text. Inspect why the result remains PROMOTE: the method contract did not change.
2. In the same learner-owned file, change "time_horizon_days": 30 to "time_horizon_days": 60. Predict again, rerun the same command, and inspect HOLD plus time_horizon_days:expected_30. The explicit error is evidence that a changed horizon is an analysis decision, not harmless metadata.

The reusable twelve-question contract

Carry this checklist into HEALTH.5–7 and the capstone. If a question is unanswered, the next move is not “pick a test”; it is “repair the contract.”

1. What is the question and estimand?
2. What are the population and unit of analysis?
3. What is the outcome type and scale?
4. How many groups, times, or conditions exist?
5. Are observations independent, paired, or repeated?
6. How was the sample obtained, and which biases are plausible?
7. Are missingness, outliers, unit errors, or coding errors present?
8. Are assumptions reasonable for the design and data?
9. Was the analysis prespecified, and how many comparisons are planned?
10. Which method directly estimates the effect of interest?
11. Which effect, interval, and diagnostic accompany the p-value?
12. Which limitations prevent causal or population-level generalization?

Review route: repair only what is uncertain

Use the route generated above, or browse all eight repairs. Each is deliberately small: complete it, return to the diagnostic, and change “review” to “ready” when you can explain the idea in your own words.

Your turn: write the five-line study card

Without software, write five lines for AURORA-30: population, unit, outcome, comparison, and dependence. If any line is vague, return to the matching readiness signal. If all five are concrete, you are ready for HEALTH.1; the first run and the two-change adaptation are enough programming for day one.