Resistance only helps the builder who already has thrust — a note on what AxonOS needs next.
There is a saying founders like: a plane takes off against the wind.
It is true, and the precise version is more useful than the slogan. Pilots take off into the wind because a headwind lets the aircraft reach takeoff airspeed at a lower groundspeed, so it leaves the ground after a shorter run. But the wind does not fly the aircraft. Lift comes from the wings moving through the air, and it is the engines' thrust that moves them fast enough. A headwind is an advantage only for an aircraft that already has fuel in its tanks.
I have been thinking about that distinction a lot while building AxonOS.
AxonOS is an infrastructure layer between neural hardware and the software — increasingly AI — that uses neural data. Not a headset, not a decoder, not an application: a deterministic runtime and permission layer.
The reason it has to exist is simple to state. As neural systems move from the lab toward clinics and products, they inherit constraints that ordinary software stacks were never designed to guarantee: bounded latency, measured jitter, a worst-case response time you can argue rather than merely observe, and integrity of data from the ADC to the application. When the data comes from a human nervous system, access control stops being an application feature. It becomes infrastructure.
Today almost every team building a neural system rebuilds that layer for itself — and rebuilds it again when the hardware changes. AxonOS is my answer to that.
I hold one rule for everything I publish about AxonOS, and it is written down as RFC-0003: every performance, latency or correctness claim carries its evidence level — derived from instruction counts, measured on reference hardware, or validated by an independent instrument — and is never stated above the evidence that exists. Pending claims are marked pending. When I have tagged a claim above its evidence, the correction is published in the repository and stays there.
Here is what exists under that rule. Every item is a link:
- Open specifications — nine RFCs, five active and four in draft, from an EDF scheduler with biological deadlines to bounded disclosure of sealed neural data.
- A conformance suite for the intent wire format, with dependency-free codecs in Rust, Python, C, JavaScript and Java checked byte-identical against the same vectors in CI — and an open invitation to add a binding in a language it does not yet cover.
- A consent state machine whose core properties are checked by bounded model checking (five Kani harnesses in CI), with timing measured on reference hardware and labelled by evidence level.
- A signal-pipeline core — deterministic fixed-point filtering, feature extraction and classifier inference, pinned by conformance vectors and nine Kani harnesses. It deliberately publishes no accuracy, latency or power figure until one is measured.
- An acquisition gateway — an OpenBCI GUI integration fork that streams EEG into AxonOS over LSL for hardware-in-the-loop testing.
- dy-wcet — worst-case response-time analysis in
no_stdRust: zero dependencies,unsafeforbidden, eight Kani harnesses, alive demo and apublic bounty for the first counterexample. - The AxonOS Research Series here on Medium — a public design record of the architecture, its trade-offs and its open questions.
That is the airframe: designed in the open, and tested wherever it can be tested without a measurement lab and independent reviewers.
The next stage of this work is different in kind, not only in size.
Timing claims have to climb to the top evidence level: validated by an independent instrument on reference hardware, and published whatever the result. Real acquisition devices have to be integrated and supported, not only tested. Security has to be reviewed by people who did not design it. And the core has to be carried by a team built to maintain it for years.
Discipline and long nights can produce specifications, proofs and design records. They cannot produce a measurement lab, a hardware integration program or a team. That transition — from design to infrastructure — is where many hard technical projects stall. Not because the idea fails, but because the stage requires fuel the previous one never needed.
I would rather name that transition in public than pretend it isn't there.
Capital. I'm speaking with investors who understand infrastructure rather than applications — people who evaluate a deterministic runtime and a permission model on evidence, not narrative. The technical record is public; deeper diligence material is available under NDA.
Hard problems. If you build neural hardware, robotics, edge or other latency- and safety-sensitive systems, you may have a problem I can solve now. Through DY Research I take on narrowly scoped, fixed-price engagements: WCET and timing analysis, determinism and concurrency review, latency and jitter analysis of real-time signal pipelines, security architecture for neural data, and technical due diligence of real-time systems. Written, rigorous, one clearly defined deliverable.
People. I'm assembling the team for the next stage: senior Rust and real-time engineers, BCI signal-processing engineers, and advisors in clinical neurology and medical-device regulation. If you want to be early in the layer neural systems will run on, I'd like to hear from you.
Doors. If you can open a commercial or strategic door — a hardware partner, a lab, a program heading toward trials — that materially accelerates this work, let's talk.
The resistance is real: a young category, long sales cycles, regulators still deciding what neural data even is. I don't mind it. For an aircraft with thrust, a headwind shortens the runway.
The design is public. The direction is clear. The next leg needs fuel — and the right people on board.
— Denis Yermakou Founder, AxonOS
[axonos.org](https://axonos.org) · [medium.com/@AxonOS](https://medium.com/@AxonOS) · [connect@axonos.org](mailto:connect@axonos.org)
Open source: [github.com/AxonOS-org](https://github.com/AxonOS-org)
© The AxonOS Project / Denis Yermakou