The honest questions.

A collective. The core contributors are a mix of neurosurgeons, computational scientists, infrastructure engineers and patient-advocates, organised as a non-profit council rather than a company. There is no parent corporation, no equity-as-loss subsidiary, no investor stack. Funding comes from research grants, hospital pilot fees and a small set of mission-aligned foundations — all disclosed in the council ledger.

Nowhere, structurally. AURORA has no physical HQ. The council convenes online and meets in person quarterly, rotating between pilot-site cities. The legal vehicle is a Dutch stichting (foundation) for governance simplicity — but the platform is jurisdiction-neutral and the code is mirrored across four continents.

Substrate is the layer below the disease modules — the federation runtime, consent metadata, audit log, signed-update plane, and the equity-as-loss machinery. Modules sit on top of substrate and inherit its guarantees. You can read AURORA as "substrate + eight modules at pilot, more on the way."

There are. None of them open the weights, the dataset hashes, the equity audits or the runtime. Most of them silo data, charge per-procedure, and lock institutions in. We think the substrate of clinical decision-support should be open the way the substrate of the web is open — and that the surgical community is the right group to own it, not a single vendor.

Both, in that order. The pilot is a research instrument: structured deployments at partner sites with publication obligations. The platform is a product in the sense that it is engineered to be installed, operated and audited by people who are not its authors. We do not plan to sell it. We plan for it to be cheap and durable to run.

Not in the pilot, and not as a platform. AURORA is research and decision-support infrastructure. Specific modules destined for clinical use will be validated and submitted to regulators by the partner institutions deploying them; the underlying code remains open and the audit artefacts (model card, equity report, dataset hashes, weights hash) ship with the submission. We do not file as a single device manufacturer because we are not one.

No. Every module is built around the principle that the clinician is the override. AURORA scores a decision, surfaces the evidence behind the score, exposes its uncertainty, and logs the call. If the surgeon disagrees, they override — and that override is part of the dataset, not an exception to it.

Eight modules at pilot: AURORA-GLIO (gliomas), AURORA-SPINA (spina bifida), AURORA-TC (tethered cord), AURORA-HYDRO (hydrocephalus), AURORA-DWM (Dandy-Walker malformation), AURORA-ENCEPH (encephaloceles), AURORA-CRANIO (craniosynostosis) and AURORA-ARACH (arachnoid cysts). Each module has its own RFC, dataset, and equity threshold.

Spine deformity, functional epilepsy, and trauma triage are the leading candidates for the next RFC round in 2027. Module proposals are public and council-debated; community members can sponsor or co-author them.

No. It instruments the tumour board. AURORA-GLIO's outputs are designed to be projected onto the MDT screen — molecular stratification, surgical-corridor candidates, post-op risk panels — so that the board reaches a faster, better-evidenced consensus. The decision is still the board's.

Yes — and that is a structural commitment, not a marketing line. Modules ship with a degraded-input mode that accepts photo-only intake (for example, CRANIO-DIAGNOSTICS) and a compute-light variant that runs on a single workstation. The federation runtime supports intermittent connectivity and air-gapped operation.

No, but several of them (SPINA, CRANIO, DWM) are paediatric in their primary cohort because that is where the open-data gap is widest and the equity argument strongest. Adult-cohort variants are part of the post-alpha roadmap.

Only the data your institution chooses to expose, and structurally never in the form of a central database. AURORA has no central data lake. Pilot sites run the platform on-prem or inside their own VPC. The federation runtime traverses signed model updates between sites; it does not move patient records.

In a sharing model, every site sends a copy of its records to a central pool, and the central pool trains a model. In federation, the training happens at each site on each site's own records, and only the model deltas — small, hashed, signed, and rate-limited — leave the site. Patient records never leave the institution that collected them.

Yes. Federation is opt-in per-module and per-cohort. A site can run AURORA in local-only mode, where no model deltas leave the building — they get a frozen baseline model and their own fine-tuning never reaches the network. They still get the audit log and the substrate guarantees.

Consent metadata is a first-class object. Every record carries the cohort policy under which it was collected. Subsystems with an explicit consent dependency refuse to run on records that lack the matching policy. If a cohort's policy disallows a particular use, the federation runtime will not include those records in that training run — and the audit log says so.

Differential-privacy budgets are configured per registry and enforced by the runtime. Budgets surface in the audit log so partner sites can see exactly how much privacy budget a given training run consumed. DP is one tool among several; we don't oversell it.

No. No cookies for analytics, no fingerprinting, no third-party trackers. The only external assets are Google Fonts and the unpkg-hosted React/Babel CDN — both content-pinned with subresource-integrity hashes. The full privacy posture is documented at /privacy.

Yes — through the hospital, under your local law. AURORA's substrate does not change your existing rights (GDPR, HIPAA, India DPDP, etc.); it inherits them. We strongly support those rights and will not, and structurally cannot, override the institution-patient relationship.

MIT, at public alpha (Q4 2026). All eight modules, the substrate, the CLI, the dashboards and the example deployments are MIT. Documentation is CC-BY 4.0.

Because adoption matters more than enforcement. Hospitals, vendors and researchers should be able to use, fork or embed AURORA without legal review. The community is the moat — the license should not be. We considered AGPL and rejected it on the grounds that a single non-permissive surgical platform would be re-implemented behind closed doors instead of contributed back.

Yes. Weights are published under MIT alongside the code at every release. Each weights drop ships with a model card, an equity audit report, the training-data hash set, the federation-run audit log, and a reproducibility recipe.

Where we control them and licensing permits, yes — published as datasets with DOIs and cohort-policy metadata. Where we do not (pilot-site cohorts under hospital ethics), the dataset is not published, but the hash is, and a third party can verify that the published weights were trained against the claimed records.

Yes. MIT permits that, and we encourage it. We ask (not legally require) that vendors contribute back, name AURORA in their model cards, and respect the equity-as-loss commitments. We will publicly call out vendors who strip those out.

The non-profit foundation. Use of the name in a clinical-product context requires a trademark licence to ensure the equity-as-loss commitments travel with it. Use in research, teaching and citation does not.

Stratified performance is part of the loss surface, not a post-hoc audit. For every released module we define a stratification set — typically ancestry, sex, age band, socioeconomic proxy and access proxy. During training, the loss function carries a penalty for predictive disparity across those stratifications. If a model can only reach its top-line metric by performing badly on a subgroup, training does not converge.

Then the release is blocked. There is no exception path for marketing reasons. Thresholds are revisable, but only by RFC, in public. The position is deliberate: if a module's top-line metric requires hurting a subgroup, the top-line metric is wrong — not the subgroup.

Two permanent patient-advocate council seats with veto rights at release. Patient-facing surfaces (consent flows, model cards, plain-language summaries) require advocate-seat sign-off. The advocates are not advisory; they are structural.

Through an open call, screened by the council for lived-experience relevance and absence of conflict-of-interest. Seats rotate on a three-year term with a one-term limit. Advocates are paid; their time is not extracted.

The runtime watches stratified performance continuously where the deployment exposes it. If a module crosses its threshold in production, it self-quarantines: predictions still surface but are flagged as out-of-spec, the council is notified, and a recall RFC is triggered. We have never had to do this in pilot; the path exists because we expect to one day.

Three channels, all reaching different humans. ethics@aurora.health reaches the independent ethics-seat holders (not on the core team). advocates@aurora.health reaches the patient-advocate council seats. security@aurora.health reaches the privacy and security desk and is triaged within 72 hours. Anonymous reporting is supported.

Through the Join page or by emailing pilot@aurora.health. We accept applications on a rolling basis from hospitals, research groups, developer collaborators and patient-advocate organisations. Clinical pilot sites go through a scoping call, an IRB/ethics handshake, a federation-readiness check, and a 90-day soft launch.

A pilot fee scaled to institutional size, covering implementation support and the federation-runtime overhead. The fee is published openly on a tier table; there is no haggling and no NDA. Low-resource institutions can apply for the equity tier, which is fee-waived and underwritten by the foundation. No pilot site is turned away for inability to pay.

Yes. Air-gapped Helm and offline OCI bundles are first-class deployment targets. Telemetry is opt-in and off by default. A site can deploy AURORA, train on its own cohort, and never connect to the federation — and we will still support it.

A single GPU workstation (24GB) is sufficient for the compute-light modules and the diagnostic UIs. The training and federation roles want a small cluster — three nodes with NVMe storage and one GPU per node is the comfortable floor. Imaging-heavy modules (GLIO, CRANIO 3D) benefit from more, but degrade gracefully.

Two-to-six weeks from contract to soft-launch, depending on the IT environment and the module set. The federation handshake, audit-log integration and consent-metadata wiring are the time sinks; the actual AURORA install is hours.

Operational telemetry shared back with the council (opt-in, anonymised by default), a quarterly equity-report review, and participation in at least one published replication study. We do not ask for branding rights, data ownership transfer, or non-compete clauses.

Yes. The substrate is module-scoped and site-scoped; a paediatric-neurosurgery department can run AURORA-CRANIO and AURORA-SPINA without committing the wider hospital. Most pilots start that way.

It means a piece of software helped your surgeon weigh the evidence and frame the conversation — it did not make the decision. AURORA reads the relevant imaging, prior records and protocols and produces a summary, a set of options, and the uncertainty around each. Your surgeon read that, talked it over with the team, and decided. The override always sits with the clinician.

No. AURORA is not the decision-maker, and the platform is structurally built so it cannot become one. Every module is configured to require a clinician override on every recommendation — there is no auto-action path.

Possibly, under your institution's research consent and only if you opted in or were covered by your hospital's research ethics approval. You can ask the hospital exactly which records of yours were included and in which model versions; AURORA's audit log makes that question answerable.

Yes, through your treating institution. The output of any AURORA module on a specific case is part of the medical record. The plain-language summary is written for you, not for the team — that is intentional, and it is a deliberate design constraint enforced by the advocate council.

Email advocates@aurora.health with a short note about your background and the disease area you care about. The advocate seats rotate, and the working groups around each module have advocate slots open between rotations. Honoraria and travel are covered.

Through an RFC with clinical sponsors and a credible plan. The council reviews, debates, and — with quorum — allocates compute and a module skeleton. The first eight modules followed this path during pilot. RFCs are public and reviewed in the open.

Yes, and we need you. Roughly half of the substrate work — federation runtime, audit log, signed-update plane, dashboards, deployment tooling — is infrastructure engineering. The other half is clinical and statistical. Contributors are paired across that line on every working group.

Python and PyTorch on the model side, Rust on the federation runtime and signed-update plane, Go on the audit-log service, and a static React-based dashboard. Deployments are Helm-on-Kubernetes (with a single-node Compose variant for compute-light sites). Sigstore for signing, OCI for artefacts. Boring is a feature.

github.com/aurora-collective at public alpha. Today (private pilot) the code lives on a self-hosted Forgejo accessible to council members and pilot sites. We mirror everything at alpha; nothing is held back.

PRs against the relevant module repo, with a CLA-free DCO sign-off. Substrate changes require two council reviewers from different working groups; module changes require sign-off from the module's clinical sponsor. Equity-relevant changes additionally require advocate review.

Yes, modest, foundation-funded. Sustained contributors can apply for a quarterly stipend so that the people doing the unglamorous infrastructure work — auditing, replication, documentation — are paid for it. The stipend is published on the ledger.

Three sources, in roughly equal thirds: research grants (Wellcome, NIH, ERC and equivalents), pilot fees from partner institutions, and mission-aligned foundations. There is no private investor capital and no equity stack. Every funder is named on the ledger and the council declares conflicts before each vote.

Structurally hard. No funder may exceed 25% of annual budget; over-cap contributions are returned. Funders do not get council seats by virtue of funding. The MIT license means that if the foundation were ever captured, the community could fork the substrate intact.

Twelve seats. Two patient advocates (rotating), four clinician seats (rotating across specialties and continents), three engineering seats, one statistics/equity seat, one ethics seat (independent), and one community-elected seat. Council membership and term lengths are on the public ledger.

RFC + supermajority vote. The RFC is published, debated for at least 28 days, revised, and put to a supermajority (two-thirds) council vote. Substrate-breaking, equity-threshold-loosening and license-changing decisions require unanimous patient-advocate sign-off.

There is a dissolution clause. The trademark passes to a stewarded escrow at a sibling open-science foundation; the code is already mirrored across four continents and continues to live without us. The dissolution playbook is published — we wrote it on day one, because resilience is a substrate property.