Roadmap

How to read this roadmap

The project is currently in the public foundation stage.

Current status

Stage 0 — Public foundation

Goal: make the proposal inspectable, challengeable, attributable, and safe to contribute to.

• ✓ Publish a clear status statement, vision, roadmap, and architecture overview.
• ✓ Establish MIT code licensing and CC-BY-4.0 content licensing.
• ✓ Publish contribution, conduct, security, support, and governance processes.
• ✓ Publish curated article and infographic assets without raw platform captures. Record provenance and outstanding review limits.
• ✓ Add automated checks for formatting, links, content metadata, and the publishing build.
• ☐ Convert important unresolved design questions into trackable issues or RFCs.
• ☐ Inventory the prototypes and evidence referenced by the source documents; record what can be released, migrated, or only cited.
• ☐ Complete legal review of privacy, retention, consent, and data-sharing assumptions before accepting real participant data.

Exit gate: a new contributor can identify current artefacts, open questions, licensing boundaries, and how decisions are made without private context.

Stage 1 — Standard before scale

Goal: publish the smallest useful, implementation-independent contract.

• Define terminology and ownership for identity, organisation, membership, application, interaction, milestone, facility, session, and audit records.
• Select one narrow cross-organisation workflow to specify end to end.
• Publish machine-readable schemas, valid and invalid examples, and a version compatibility policy.
• Define extension rules so schemes and regions can add fields without silently forking the core.
• Define consent, visibility, provenance, retention, and deletion semantics.
• Build the first conformance checks around exports—not around a preferred product.
• Test the draft with founders, operators, and at least one independent implementer.

Exit gate: two independently produced datasets can pass the same validation and round-trip through the selected workflow without losing ownership, visibility, or provenance information.

Stage 2 — Minimum reference slice

Goal: demonstrate the standard through one auditable workflow, not a seven-module build.

Proposed first-slice candidates include application intake to operator triage, or mentor session to action-item follow-up. The choice must be made through an architecture and user-research review.

Required before a public deployment:

• tenant and role boundaries with automated isolation tests;
• secure identity and session handling;
• append-only audit events for sensitive transitions;
• accessible user journeys and low-bandwidth behaviour;
• documented backup, export, deletion, and incident procedures;
• threat modelling and independent security review;
• production telemetry that does not collect sensitive content by default; and
• a self-hosting guide that a team other than the authors can follow.

Exit gate: a limited pilot can run the selected workflow with real users, informed consent, verified isolation, reliable exports, and a rollback plan.

Stage 3 — Interoperability and independent adoption

Goal: prove that the standard is larger than the reference implementation.

• Add a second workflow and a second conforming implementation or adapter.
• Publish migration and compatibility tooling.
• Validate government or institutional report exports against publicly available requirements; do not imply integration approval without it.
• Establish a public RFC cadence and standards working group.
• Publish transparent pilot findings, including failures and burden shifted to users.
• Evaluate a hosted offering only after self-hosted export and portability are demonstrated.

Exit gate: an adopter can leave one implementation with a complete standard export and use that export elsewhere.

Stage 4 — Network services

Goal: add discovery and aggregate learning only when the trust foundation can support them.

Possible work:

• institution, program, researcher, mentor, and facility discovery;
• facility request and routing workflows;
• permissioned cross-tenant signals;
• public aggregate benchmarks with disclosure review;
• institution and policy dashboards; and
• evaluated privacy-preserving analytics.

Federated learning and differential-privacy claims require measurable privacy budgets, attack testing, governance, and independent review. They are not accepted merely because they appear in an architecture diagram.

Exit gate: network services create measurable participant value without weakening data control or enabling re-identification.

Stage 5 — Conformance and governance transition

Goal: make interoperability and stewardship credible beyond the founding team.

• Version the standard through a multi-stakeholder decision process.
• Operate a public conformance suite with appeal and correction procedures.
• Define any certification mark, trademark rules, and audit process in public.
• Separate commercial implementation decisions from standards decisions.
• Evaluate transition to an independent steward or representative council.

No deployment may call itself “certified” by this project until those rules, tests, and an authorised decision process exist.

Module status

Near-term contribution themes

1. Challenge the minimum standard surface.
2. Turn privacy and consent assumptions into testable requirements.
3. Document real operator workflows without exposing participant data.
4. Improve accessibility and multilingual design requirements.
5. Build content, schema, and link validation.
6. Identify a minimum reference slice and its threat model.
7. Propose governance changes through the process in GOVERNANCE.md.