Statistical Analysis Report — reproducible template

Purpose

This template helps you produce consistent, transparent statistical analysis reports that others can reproduce and review. Use it as a living document: capture the decisions you actually made, link to code and data, and record environment details so results can be re-created later.

How to use this template

Fill each section with concise, factual entries. When possible, include links to the exact data snapshot, code repository commit hash, and container or environment specification. Avoid vague statements such as “standard preprocessing” — list the operations, parameters, and the order they were applied.

Template sections (required)

1. Title and short summary

One-line title and a 2–4 sentence summary of the question, approach, and main findings (include effect sizes and uncertainty rather than only P-values).

2. Data provenance

• Data source(s) and retrieval date/time.
• Exact dataset identifiers, query or export commands, or accession numbers.
• Data access instructions and any access restrictions.
• Data snapshot used for analysis (file name, checksum like SHA256, or storage location).

3. Inclusion / exclusion rules and preprocessing

• Record filtering, inclusion/exclusion criteria with exact code or filter expressions.
• Missing-data handling: approach and thresholds (e.g., drop rows with >20% missing; impute with X method; list affected variables and counts).
• Transformations and scaling (order matters): e.g., log(x+1) then z-score, or winsorization limits.
• Derived variables: formulas and rationale.

4. Variable definitions and analytic dataset

• Provide a table of variables: name, type (numeric/categorical/date), units, permissible range, and how created.
• Attach or link to the analytic dataset codebook or CSV with headers.

5. Study design / model specification

• Primary outcome(s) and primary predictor(s).
• Study design (randomized trial, cohort, case–control, cross-sectional, time-series, etc.).
• Model family and exact specification (e.g., linear regression: Y ~ X1 + X2 + X1:X2; link function; offset; random effects structure with formula and group variables).
• Estimation method and software (package name, version, and function call example).

6. Statistical methods and parameter settings

• Hypothesis tests, alpha level, one-sided/two-sided decisions.
• Multiple comparison adjustments (method and scope).
• Power analysis assumptions (effect size, sample size, power target) if performed; attach code or tool output.
• Model selection steps (if any) and criteria used (AIC, BIC, cross-validation folds, selection algorithm).

7. Assumptions and diagnostic checks

List the key assumptions for your methods and how you checked them. Include the following checklist and link to diagnostic plots/code outputs.

• Linearity — residuals vs fitted plots
• Normality (if required) — Q–Q plots, Shapiro–Wilk where appropriate
• Homoscedasticity — scale-location plots or tests
• Independence / autocorrelation — Durbin–Watson, ACF, or study design justification
• Collinearity — variance inflation factors (VIFs) and thresholds

8. Diagnostics plots checklist

1. Residuals vs fitted
2. Scale-location
3. Q–Q plot of residuals
4. Cook’s distance / influential points
5. Leverage vs residuals

9. Results

• Primary results table(s) with estimates, standard errors, confidence intervals, effect sizes, and exact P-values. Avoid binary language such as “significant” without context.
• Model fit statistics (R2, adjusted R2, AIC/BIC, likelihood ratio tests where relevant).
• Interpretation: practical meaning of estimates, known limitations, and possible biases.

10. Sensitivity and robustness analyses

Document planned and exploratory sensitivity checks, including alternative model specifications, alternative preprocessing choices, and subgroup or stratified analyses. For each, include code link and brief result summary.

11. Reproducibility checklist (required)

• Code repository URL and exact commit hash or snapshot used.
• Script or notebook entry point (file name and command to run).
• Compute environment: OS, language runtime (e.g., R 4.2.1, Python 3.10), and package versions. Prefer an environment specification file (requirements.txt, environment.yml, renv.lock, or conda-lock).
• Container or VM image (Dockerfile, image tag) if used.
• Random seeds and how randomness was controlled (which functions were seeded and where).
• Exact commands to regenerate all figures and tables (or a build script/makefile).
• Data access steps and any required credentials (describe and provide contact or procedure for access if restricted).

12. Appendices and artifacts

• Raw output files or a link to an artifacts folder (e.g., model objects, intermediate datasets).
• Full code listing or notebook export (HTML/MD) for human reading.
• Alternative analyses and exploratory plots kept for transparency.

13. Author, date, and version

Name(s) of analyst(s), contact info, date of report, and a report version identifier. Record any subsequent changes and why they were made.

Minimal example entries (illustrative)

Data provenance: ClinicalTrialsDB export v2026-07-01.csv (SHA256: abc123...), retrieved 2026-07-01. Query: SELECT * FROM participants WHERE enrolled_date < '2025-01-01'.

Model specification: Linear mixed model, outcome = blood_pressure, fixed effects = treatment + age + sex, random intercept by clinic, estimation via lmer (lme4 1.1-31) on commit 0f5a7e.

Quick reproducibility metadata (copyable JSON snippet)

{
  "data_snapshot": "s3://my-bucket/exports/clinical_v2026-07-01.csv",
  "data_sha256": "abc123...",
  "code_repo": "https://git.example.org/my-study.git",
  "commit": "0f5a7e",
  "entrypoint": "scripts/run_all.sh",
  "environment": {
    "r_version": "4.2.1",
    "packages": {"lme4": "1.1-31", "tidyverse": "1.3.1"}
  },
  "container": "registry.example.org/my-study:2026-07-01",
  "seed": 42
}

Reporting notes and good practices

• Prefer effect sizes and confidence intervals over sole reliance on P-values.
• Pre-register primary analyses where practical and note deviations clearly.
• Distinguish pre-planned from exploratory analyses.
• When sharing restricted data, provide a reproducible pipeline that runs on a public synthetic dataset and explain differences from the restricted dataset.

Where interactivity can help

This template maps naturally to an interactive reproducibility form (fields for data snapshot, commit hash, environment file, etc.) so teams can collect structured metadata and store it with the report. See CapabilityEnhancementNotes for implementation ideas.