RESEARCH

The working papers behind the pilot.

Working drafts, whitepapers, protocol RFCs and replication runs from across the eight pilot modules. Everything ships with the code that produced it; nothing is paywalled. DOI-stamped at public alpha.

6 drafts in flightQ4 ’26 · DOIopen
I · Preprints & whitepapers

Drafts in flight.

Open drafts produced by the module teams and pilot collaborators. Each has a public review thread and a maintainer responsible for the next revision. Status badges reflect the live state of the draft.

Drafts move through four states: scoping (problem outlined, no methods locked) → writing (methods + early results) → in review (open community + module-lead review) → DOI-stamped (at public alpha, with frozen artefact hashes attached). Anyone can comment on any draft; comments are public and resolution is logged with the document.

III · Datasets

Datasets we build on.

AURORA does not own data. We connect to permissively-licensed open datasets and to federation partners' on-prem registries. Each dataset is annotated against the modules that depend on it.

TCGA-GBM/LGG

Glioma imaging + omics

The Cancer Genome Atlas glioma collections — foundational for AURORA-GLIO foundation-model pre-training and evaluation.

BraTS

Brain tumor MRI

Multi-institutional MRI segmentation challenge data; benchmark substrate for AURORA-GLIO and infiltration modules.

MOMS-aligned cohorts

Spina bifida outcomes

Public summaries from the Management of Myelomeningocele Study underpin AURORA-SPINA prenatal decision priors.

HCP & UK Biobank

Healthy controls

Population priors on brain anatomy and CSF compartment volumes across modules.

OASIS-3

Longitudinal MRI

Long-horizon imaging used in compartment lifetime modelling and incidental-finding triage.

Open Neuro

Multi-modal neuroimaging

BIDS-formatted open datasets across paediatric and adult imaging used for federated evaluation.

IV · Evaluation protocols

How we decide something works.

Every module ships with an evaluation protocol — held-out splits, metrics, stratifications, and the explicit failure modes the protocol catches. Protocols are versioned alongside the models they evaluate.

P-01

Held-out splits

Patient-level (never image-level), stratified by site, ancestry, sex and age band. Splits are pinned and signed.

P-02

Primary metrics

One per module — AUC for triage, sigma for tension fields, Brier for calibration. Secondary metrics carry their own thresholds.

P-03

Stratified scoring

Every metric reported per stratum, not just aggregate. A drop below the equity threshold blocks release.

P-04

Failure-mode tests

Adversarial slices the protocol must catch — domain shift, missing modality, sample-size cliff. Listed publicly per module.

P-05

Uncertainty

Calibration reported with each metric. Brier and ECE on top-line outputs; confidence bands on derived fields.

P-06

Drift watch

Continuous evaluation against the same protocol every quarter. Drift > threshold opens an RFC, not a hotfix.

V · Replication tracker

Reproducible, or it didn't happen.

A running ledger of independent reruns of AURORA results. Pinned commit + image + weights + dataset hash means anyone with the right hardware can re-execute. If a result stops replicating, we say so — the tracker turns red and an issue auto-opens.

LIVE · 2026-05-12
5replicating·2drift·1broken
8
total reruns
8
sites
≤ 0.05
drift target
auto
issue on red
PIN SET · WHAT WE GUARANTEE PER RESULTSix hashes pinned per run. If any change, the run is flagged for re-validation.
Commit
a1b2c3d4e5f6
git
Image
sha256:c9a4…f17e
OCI
Weights
sha256:7b1e…aa9d
Sigstore
Dataset
sha256:f2c0…12bb
Croissant
Protocol
P-04 · v1.2
AURORA-EVAL
Env
CUDA 12.4 · py 3.11
container
MODULE · SUBSYSTEM
SITE
HARDWARE
DATE
DRIFT
STATUS
AURORA-GLIO
GLIO-AI · v0.9
Karolinska
A100 ×4
2026-05-12
Δ 0.012
replicating
AURORA-GLIO
GLIO-INFIL · v0.7
UCSF
H100 ×2
2026-05-08
Δ 0.041
replicating
AURORA-CRANIO
CRANIO-DIAG · v0.8
Boston Children's
RTX 6000
2026-05-04
Δ 0.018
replicating
AURORA-HYDRO
HYDRO-DECIDE · v0.5
Charité
L40S
2026-05-01
Δ 0.063
drift
AURORA-SPINA
SB-PRENATAL · v0.4
Necker
A100 ×2
2026-04-22
Δ 0.029
replicating
AURORA-CRANIO
CRANIO-PHYS · v0.6
GOSH
CPU-only
2026-04-18
Δ 0.094
drift
AURORA-GLIO
GLIO-DIAG · v0.7
SickKids
H100
2026-04-11
Δ 0.021
replicating
AURORA-TC
TCS-SIGNAL · v0.3
Bambino Gesù
RTX 4090
2026-04-03
Δ 0.155
broken
WHAT THIS GIVES

A re-runnable bundle, per result.

One command pulls the pinned commit, pinned image, pinned weights and the dataset hash for the cohort the result was reported on. Anyone with the hardware can run it.

WHAT IT DOESN'T

It doesn't generalise on your data.

Replication ≠ external validation. A result replicating on its own bench does not mean it works at your site. That's exactly why federation matters and why module pages carry both numbers.

IF SOMETHING'S RED

An issue opens automatically.

The tracker monitors drift on every quarterly rerun. A red row creates a public GitHub issue tagged with the responsible maintainer. Resolution is logged in the artefact's history.

If a result stops replicating, we say so. The tracker is a feature, not a press kit.

Reproducibility is unsexy infrastructure work. The current state of clinical-AI literature is what happens when it is treated as optional. AURORA treats the ledger above as the canonical record — papers are interpretations of it, not the other way around.

VI · How to cite

Cite the artefact, not the headline.

Every AURORA result, model and dataset has a citable artefact with a DOI at public alpha. Cite the artefact you actually used — not a higher-level umbrella paper that obscures which version of which subsystem ran.

BibTeX (template)

cite.bib
@software{aurora_glio_2026,
  title     = {AURORA-GLIO: An open substrate for glioma},
  author    = {{AURORA Collective}},
  year      = {2026},
  version   = {0.9.0-pilot},
  url       = {https://aurora.health/glio},
  doi       = {10.0000/aurora.glio.0.9.0},
  note      = {Pinned commit a1b2c3, weights sha256: c9a4…f17e}
}

Module-specific entries (e.g. aurora_glio_infil_2026) exist for every subsystem. The note field carries the pinned commit and sha256 of the artefact you ran — that's the line that lets reviewers replicate you.

What we ask in return

  • If you publish on top of AURORA, cite the version-pinned artefact, not the project name.
  • If a result you publish breaks under a later AURORA version, file an issue — drift signal is the most valuable feedback we get.
  • If you fork AURORA, name your fork. The MIT license requires nothing here; the community asks anyway.
Changelogv0.6.0