Each RFC records the reasoning, alternatives, formal model, and acceptance criteria for one architectural decision.
Index · Process · Reading order · Stack · License
A real-time kernel for safety-critical brain-computer interface systems cannot be built by accreting code commits. The decisions that will matter most — scheduler choice, memory ordering, isolation model, validation framework — must be defensible in writing, reviewable by independent engineers, and citable when the regulatory submission asks "why this approach."
This repository is the public record of those decisions.
The format is adapted from the Rust RFC process and the IETF RFC tradition, with adjustments for the safety-critical-systems context.
| # | Title | Status | Track | Updated |
|---|---|---|---|---|
| 0001 | EDF Scheduler with Biological Deadlines |  |
scheduling | 2026-04-25 |
| 0002 | Zero-Copy Ring Buffer for Signal Path | |
memory | 2026-04-25 |
| 0003 | Validation Status Framework (L1/L2/L3) | |
process | 2026-04-25 |
| 0004 | Dual-Core Real-Time Contract | |
scheduling | 2026-04-25 |
| 0005 | Capability-Based Application Manifest | |
security | 2026-04-25 |
| 0006 | Intent Wire Format ABI |  |
api | 2026-05-15 |
— being drafted, not yet ready for review
— ready for review, comments open in Discussions
— accepted, implementation underway or complete
— implementation complete and stable
— replaced by a newer RFC; RFC remains visible for history
— withdrawn before acceptance
- scheduling — real-time scheduling, deadline analysis, timing contracts
- memory — memory ordering, allocation discipline, cache model
- security — isolation, attestation, capability model, consent enforcement
- process — engineering process, validation methodology, evidence standards
- hardware — reference hardware, certification requirements, BOM constraints
- api — application-facing interfaces, SDK design
The lifecycle of an RFC is:
draft ──────► review ──────► active ──────► final
│
└────► superseded (by future RFC)
│
└─► withdrawn (before acceptance)
- Open a discussion in the RFC ideas category to gauge interest. State the problem, not the solution.
- If the problem is in scope, fork this repository and copy
templates/0000-template.mdtorfcs/NNNN-short-title.mdwhereNNNNis the next free number. - Fill in every section. The "Reference-level explanation" section must be detailed enough that an independent engineer can implement against it.
- Open a pull request titled
RFC-NNNN: <title>. - Substantive feedback is collected for a minimum of 14 calendar days before merge.
- Acceptance criteria: at minimum, no unaddressed objection from a maintainer, and the proposing author has revised in response to all written feedback.
- On merge, status becomes
activeand an implementation tracking issue is opened in the relevant code repository.
- Architecture or interface decisions that will be hard to reverse later
- New cross-cutting concerns (a new state, a new safety property, a new IPC class)
- Changes to validation, evidence, or compliance methodology
- Changes that affect the regulatory submission narrative
- Bug fixes — file an issue
- Refactors that preserve external behaviour — open a pull request
- Performance optimisations that do not change interfaces — open a pull request
- Day-to-day engineering choices — make them in code review
If unsure, ask in Discussions before opening an RFC.
RFCs are accepted on technical merit and engineering rigour. The following do not count as objections:
- Stylistic preference unless it affects readability for a non-author engineer
- "I would have done it differently" without a stated reason that the alternative is materially better
- Concerns about implementation effort — these belong in the implementation issue, not the RFC
The following do count as objections:
- A specific failure mode the RFC does not address
- A specific safety property the RFC violates
- A specific regulatory standard the RFC contradicts (with citation)
- A specific better alternative with a stated trade-off analysis
If you are an engineer evaluating AxonOS:
- Start with RFC-0003 (Validation Status Framework). It explains how AxonOS distinguishes claims by evidence level. Every other RFC's claims classify themselves under this framework.
- Then read RFC-0001 (EDF Scheduler) for the core scheduling argument.
- Then RFC-0004 (Dual-Core Contract) for the partition model.
- The remaining RFCs can be read in any order.
If you are reviewing for clinical or regulatory engagement:
- RFC-0003 (Validation Status Framework) — the evidence taxonomy
- RFC-0004 (Dual-Core Contract) — the partition and fault containment model
- RFC-0005 (Capability-Based Manifest) — the application isolation model
If you are an investor evaluating engineering rigour:
- RFC-0003 (Validation Status Framework) — the founder's posture toward overclaiming
- Browse the index — the existence of an RFC process is itself the signal
These RFCs are the engineering record behind the canonical
axonos-standard. An RFC
becomes normative once finalised and folded into the Standard.
| Layer | Repository | Role |
|---|---|---|
| Canonical standard | axonos-standard |
Architecture manual, conformance criteria, validation taxonomy |
| Engineering RFCs | axonos-rfcs |
Numbered design proposals (this repository); normative once finalised |
| Kernel substrate | axonos-kernel |
EDF scheduling, SPSC IPC, capability gate, monotonic time |
| Application boundary | axonos-sdk |
Typed intents, manifests, ABI-compatible integration |
| Consent layer | axonos-consent |
Deterministic consent state machine and stimulation-gating protocol |
| Mesh coordination | axonos-swarm |
Distributed timing, co-availability, peer health monitoring |
| Acquisition gateway | axon-bci-gateway |
OpenBCI GUI integration fork for EEG input |
Each RFC's reference-level section maps to an implementation in one of the code repositories above.
The contents of this repository — including all RFC documents — are licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC-BY-SA-4.0).
You may freely:
- Quote, paraphrase, and cite the RFCs
- Translate them into other languages
- Use them as the basis for your own RFCs (with attribution and the same license)
The axonos-consent Rust source code, referenced from several RFCs as the canonical implementation, is dual-licensed Apache-2.0 OR MIT in its own repository — not under CC-BY-SA-4.0. Different artifacts, different licenses.
- General, partnership, and clinical engagement: connect@axonos.org
- Security disclosures: security@axonos.org
For substantive RFC discussion, please use GitHub Discussions rather than email — public technical record is the point.
The AxonOS Project · axonos.org · connect@axonos.org · security@axonos.org
medium.com/@AxonOS · github.com/AxonOS-org
Singapore · Zurich · Berlin · Milano · San Mateo
The RFC process is how the kernel earns the right to be called real-time.