AURORA-30 is the course’s practice world.
It is a wholly fictional teaching cohort: 30 synthetic records, no real participants, institutions, interventions, or outcomes. Its purpose is to let one analysis story recur across the course. It is not clinical evidence, medical advice, or authorization to conduct research.
Keep three things separate
The cohort is the fictional scenario. The data are local teaching files that represent it. The executable is a deterministic check of a teaching artifact. A passed check confirms only the criterion it reports; it does not validate a clinical claim. This separation reflects the broader need to make objectives, variables, analysis, and reporting traceable; see the public STROBE checklist for observational-reporting context.
Start with the question, then inspect the files
In HEALTH.1, AURORA-30 is used to practice turning a plain-language question into an analysis plan. The supporting files live inside the corresponding lab. Do not treat the labels or values as a template for real participant data.
Optional first execution
Open the lab’s README first. It contains the current run command, expected output, what you may change, and the limits of its verdict. From that lab directory, the prepared Python route is:
python analysis_plan_contract.py --input samples/aurora30_plan.json --lang en --format text
PROMOTE means the supplied didactic artifact met that lab’s structural check. It does not establish external validity, treatment benefit, analytic competence, or permission to use real data.When to come back here
Return whenever a later module introduces a new AURORA-30 artifact: a data audit, descriptive profile, comparison, model, or final evidence report. The fictional cohort stays constant; the question and evidence required for each artifact become more specific.