Project Runemate v1.0 v1.0 — Native DSL Compiler + TARA Safety
In plain English
Future brain implants will need to send information into the brain — not just read signals out. That means the chip inside someone's skull needs to receive content and turn it into something the brain can perceive: images, sounds, or touch sensations.
The problem is that this content needs to be tiny (brain chips run on almost no power), safe (you can't reboot a brain), and secure against future threats (quantum computers will eventually break today's encryption — NIST finalized post-quantum standards in August 2024 — and you can't change your neural data like a password).
Project Runemate is a special-purpose language and compiler designed for exactly this. It takes descriptions of what a person should see, hear, or feel, and compresses them into a format small enough and safe enough to run on an implanted chip — while using encryption that even quantum computers can't crack.
There is no open standard for this today. HTTPS, TCP/IP, and TLS all started as open research before they became the foundation of secure web browsing. Project Runemate is that kind of early groundwork — an open-source foundation for a technology that doesn't have one yet. The technical details follow below.
A native declarative DSL for multimodal BCI rendering. Compiles visual layouts, auditory tones, and haptic pulses into compact Staves bytecode — achieving 65–90% size reduction over equivalent web content.
Not a translation of web technology. A purpose-built language for neural interfaces. The Staves DSL has a closed vocabulary: if it compiles, it is safe. No sanitization needed because there is nothing to sanitize.
Above ~23 KB of equivalent content, a PQ-secured Staves payload is smaller than the same interface sent over classical TLS with raw HTML. Post-quantum security becomes not just viable on implants — it becomes more efficient than what we have today.
Runemate Forge is the native DSL compiler. It parses Staves source through a hand-rolled lexer and recursive descent parser, validates TARA safety bounds at compile time, and emits a dense bytecode stream that a minimal on-chip interpreter can render directly.
How BCIs Work Today
No commercial BCI ships inward rendering today. Every current-generation implant is outward-only: the chip records neural signals and streams them to an external device. All decoding, all UI rendering, all user interaction happens on a phone or tablet app.
Project Runemate is designing for the next generation: implants that receive content inward and render it directly to cortical tissue. That chip must decode, safety-check, and render a payload on bare metal with no phone in the loop.
Today's BCIs (Neuralink N1, BrainGate, etc.)
Inward-rendering BCIs (what Runemate targets)
Research Prior Art
Beauchamp et al. 2020 (Cell)
Drew letter shapes on V1 via microstimulation — subjects identified them
Flesher et al. 2021 (Science)
Produced tactile percepts via intracortical microstimulation in human S1
BrainGate (ongoing)
Demonstrated cursor control and typing via motor cortex recordings
All citations require manual DOI verification per our Citation Verification Protocol.
The Problem
The NIST post-quantum standards (ML-KEM, ML-DSA) are finalized. They are mathematically sound against quantum computers. They are also enormous.
A single ML-KEM-1024 public key is 1,568 bytes — compared to 32 bytes for X25519. ML-DSA-87 signatures weigh 4,627 bytes versus 64 for Ed25519. A full PQ handshake adds roughly ~20.6 KB of overhead before a single byte of application data moves.
For a server farm, this is a rounding error. For a brain-computer interface running on harvested body heat and a coin-cell battery, it is a dealbreaker — unless you compensate elsewhere.
Why not HTML?
HTML is Turing-complete — its scripting surface (JavaScript, event handlers, data: URIs) creates an unbounded XSS attack surface. It carries a massive parser dependency graph: a compliant HTML5 parser alone is ~100K lines of code. HTML was designed for screens, not brains. Its complexity is the antithesis of what a safety-critical implant needs.
Classical (Today)
Post-Quantum (NIST)
The Insight
The handshake is a fixed cost — paid once per session, amortized across every subsequent payload. The real bandwidth is in the content. And HTML is the wrong starting point entirely.
Rather than compressing HTML, Project Runemate eliminates it. The Staves DSL is a closed vocabulary: every valid keyword, element type, and attribute is known at compile time. If the source compiles, it is safe. There is no JavaScript to strip, no URLs to sanitize, no unbounded complexity to contain.
The compiler rejects unknown constructs at build time — not at runtime inside a patient's skull. This is safety by construction, not safety by sanitization.
The crossover is at roughly ~23 KB of equivalent content. Above that threshold, PQ handshake + Staves payload is smaller than classical handshake + raw HTML. Quantum-resistant security is free — and then it starts saving bandwidth.
Staves Compression Techniques
Native DSL opcodes
Purpose-built language compiles directly to bytecode — no HTML parsing overhead
String table dedup
Shared string pool with 2-byte indices; identical strings stored once
Style table dedup
Identical style sets collapsed into a single table entry, referenced by index
Multimodal encoding
Tone and pulse entries packed into 8-byte compact representations
Closed vocabulary
Compile-time rejection of unknown elements — no runtime validation needed
Safety by construction
No JS, no URLs, no executable code — nothing to sanitize or strip
The Chart
Classical + equivalent web content vs. Post-Quantum + Staves — total bytes on the wire per page load.
Crossover at ~23 KB equivalent content — PQ wins beyond this point
Amortization note: The PQ handshake (~20.6 KB) is paid once per session. With 10–50 page loads per hour on a typical BCI dashboard, net savings reach 1.6–8.6 MB/hour. PQ tax pays for itself on the FIRST dashboard load.
Streaming overhead: zero PQ difference
Real-time neural data (64ch @ 250 fps) uses AES-256-GCM with 41-byte per-frame overhead at 56.9 KB/s. Since AES-256-GCM is already quantum-resistant, PQ adds zero additional cost to the data stream. The entire PQ tax is confined to the handshake.
v1.0 Benchmarks
Real measurements from the Runemate Forge v1.0 native DSL compiler. The demo compiles a multimodal Staves source file through the full pipeline: parse, compile, encrypt, decrypt.
v1.0 Native DSL Compiler
Encryption overhead: +16 B AES-GCM. PQ handshake + compile + encrypt + decrypt verified end-to-end.
Compression visualization
Engineering Status
Transparent accounting of what's tested, what's missing, and what may change. See STATUS.md in the Forge source for the full canonical document.
Full compile pipeline, error handling, multimodal, input size limit
Tokenization, colors, units, comments
Staves, styles, tones, full documents, depth guard
Element limits, frequency, charge, bytecode size
Magic bytes, string dedup, size consistency, string/style/tone limits
Compile-disassemble roundtrip, bounds-checked reads
Compile-encrypt-decrypt roundtrip
Known Gaps
- No fuzz testing on lexer/parser
- No element balance assertion in codegen
- No Unicode control char stripping (THREAT-MODEL M8)
- No standalone CLI tool
- No benchmarks (criterion available but unused)
- Disassembler: no adversarial input tests
- Secure module: no error path coverage
Goals will evolve
The multimodal architecture is grounded in neuroscience research (topographic cortical maps), but cortical rendering is unvalidated at consumer scale. No commercial BCI does inward rendering today. As hardware matures and clinical data emerges, the bytecode format, safety bounds, and modality support may change significantly. We document what we know, flag what we don't, and update when we learn.
Why Rust
The on-chip Staves interpreter must run on bare metal with no allocator, no OS, and no tolerance for memory corruption. This eliminates Go (requires a runtime) and makes C viable but dangerous. Rust's no_std mode provides bare-metal targeting with compile-time memory safety — no garbage collector pauses, no use-after-free, no buffer overflows.
Ferrocene — the Rust toolchain certified under IEC 62304 for medical devices — provides the regulatory pathway. Type-level sanitization means that malformed bytecode is rejected at compile time, not discovered at runtime in a patient's skull. Servo's modular crates provide battle-tested layout and rendering primitives.
| Criterion | C | Go | Rust |
|---|---|---|---|
| Binary size (renderer) | ~500 KB | ~5-8 MB | ~800 KB (no_std: ~200 KB) |
| RAM floor | ~64 KB | ~2-4 MB | ~64 KB (no_std) |
| Memory safety | Manual (CVE-prone) | GC (unpredictable pauses) | Compile-time (zero-cost) |
| Sanitization | Runtime-only | Runtime-only | Type-level (compile error) |
| WASM target | Via Emscripten | ~2+ MB | ~10-100 KB (native) |
| Medical device path | Established (MISRA-C) | None | Emerging (Ferrocene IEC 62304) |
| Bare metal BCI chip | Yes | No (needs OS) | Yes (no_std) |
| PQ crypto libraries | Good | Good | pqcrypto-rs (safe wrapper) |
| Browser engine parts | NetSurf (old) | None | Servo (modular crates) |
Compiler Qualification: Ferrocene
What Ferrocene Is
Rust’s safety guarantees only hold if the compiler itself is trustworthy. For safety-critical medical devices, “trust us, it works” is not sufficient. The compiler must be independently qualified to the same standards as the device it targets. That is what Ferrocene provides.
Ferrocene is a safety-critical Rust compiler toolchain developed by Ferrous Systems. It is a fork of rustc with qualification from TUV SUD, one of the major European certification bodies. The source code is open under MIT/Apache-2.0 dual license.
Certifications
| Domain | Standard | Level | Notes |
|---|---|---|---|
| Medical Devices | IEC 62304 | Class C | Achieved January 2025. First Rust toolchain with medical device qualification. |
| Automotive | ISO 26262 | ASIL D | Highest automotive safety level |
| Industrial | IEC 61508 | SIL 3 | Functional safety |
First of its kind: Ferrocene is the first Rust toolchain to achieve IEC 62304 Class C qualification for medical devices. This is the highest software safety classification under IEC 62304, required for software whose failure can result in death or serious injury.
How Ferrocene Complements Runemate
Ferrocene operates at the compiler layer; Runemate operates at the application layer. They are complementary, not competing. Ferrocene certifies that the compiled binary faithfully represents the source code. Runemate’s TARA system certifies that the source code itself produces only safe stimulation patterns.
Concrete target: Compile the Scribe runtime (the no_std bytecode interpreter from Phase 2) with Ferrocene, targeting thumbv7em-none-eabihf (ARM Cortex-M4F / M7F). This is the exact class of microcontroller found in implantable SoCs.
Certified core library: Ferrocene’s qualified core library subset (SIL 2) covers exactly the types a no_std interpreter needs: Option<T>, Result<T, E>, str, slices, raw pointers. No heap allocation required.
Formal specification: The Ferrocene Language Specification (FLS) is the only formal specification of the Rust language. For a safety case argument submitted to the FDA, “the language behaves as specified in the FLS” is a concrete, auditable claim. Without a formal spec, there is no baseline to argue against.
Layered Neurosecurity Stack
| Layer | Component | Function |
|---|---|---|
| Compiler | Ferrocene | Certified compiler produces trustworthy binaries from source |
| App Logic | TARA Safety Bounds | Compile-time validation that all outputs are within safe stimulation limits |
| Transport | NSP + PQC Encryption | Post-quantum secure wire protocol protects data in transit |
Each layer is independently verifiable. A vulnerability in one does not compromise the guarantees of the others.
Current Limitations
- No RISC-V support. Only ARM Cortex-M4 and Cortex-M7 targets are qualified. RISC-V BCI SoCs would need a separate qualification effort.
- Qualification docs are paid. 25 EUR/month per developer for signed TUV SUD qualification documents. The compiler source code itself is free and open.
- Application-level V&V still required. Ferrocene certifies the compiler, not your code. The Scribe runtime itself must undergo separate verification and validation for FDA submission.
Status
Exploration phase. Research is underway to evaluate Ferrocene integration with the Scribe runtime. No code has been compiled with Ferrocene yet. The qualified target (thumbv7em-none-eabihf) aligns with our on-chip requirements, and the certified core subset covers our no_std needs.
Next Steps
- Build a minimal Scribe prototype with the Ferrocene toolchain
- Assess the qualification document workflow
- Evaluate cost/benefit for the project’s current stage
- Test compilation of
no_stdcore interpreter on Cortex-M4F target
Research Notes
This section is updated as research progresses.
2026-02-18: Initial Assessment
- Ferrocene source: https://github.com/ferrocene/ferrocene (MIT/Apache-2.0)
- FLS (Ferrocene Language Specification): https://spec.ferrocene.dev/
- IEC 62304 Class C = highest medical software safety class (failure can cause death/serious injury)
- Key gap: no RISC-V support limits applicability to ARM-based BCI SoCs only
- Discovered via derivation session on BCI hardware limits (Entry 66)
This section is rendered from research/ferrocene-exploration.md. Update the source document and rebuild to see changes here.
Why This Design Works
Topographic Cortical Maps
The multimodal architecture of Staves is not arbitrary. Each modality maps directly to how the brain organizes sensory information through topographic cortical maps — systematic spatial arrangements where neighboring neurons respond to neighboring stimuli.
Cortical magnification is DPI scaling for the brain: the fovea (central vision) gets disproportionately more cortical area, just as a high-DPI display allocates more pixels to critical UI elements. Staves layouts can exploit this directly.
| Modality | Cortical Map | Staves Construct | Key Research |
|---|---|---|---|
| Visual | Retinotopic (V1-V3) | stave / layout | Tootell et al. 1998 |
| Auditory | Tonotopic (A1) | tone | Formisano et al. 2003 |
| Somatosensory | Somatotopic (S1) | pulse | Penfield 1937, Flesher et al. 2021 |
Prior art: direct cortical letter perception
Beauchamp et al. (2020, Cell) drew letter shapes on V1 via microstimulation and subjects could identify them. This demonstrates that spatial information encoded in Staves layouts can, in principle, be mapped to retinotopic cortical coordinates for direct perception.
All citations listed above require manual DOI verification per our Citation Verification Protocol before use in any publication.
Multimodal Architecture
Staves v1.0 supports three modalities natively. Each compiles to compact bytecode entries and maps to a specific cortical target for neural rendering.
Visual
stave / layout
Spatial layouts rendered as visual percepts via retinotopic electrode arrays
Parameters: Position, size, color, text, borders
Target: V1-V3 (retinotopic)
Auditory
tone
Frequency-mapped alerts and feedback via tonotopic cortical stimulation
Parameters: Frequency (Hz), duration (ms), amplitude
Target: A1 (tonotopic)
Haptic
pulse
Tactile feedback mapped to body regions via somatotopic cortical stimulation
Parameters: Intensity, duration (ms), location
Target: S1 (somatotopic)
On-Chip Requirements
The Staves interpreter targets Class III medical implant SoCs. These are the minimum hardware requirements for a chip that can receive PQ-encrypted Staves payloads and render them to a cortical or retinal display.
| Requirement | Value | Rationale |
|---|---|---|
| Secure storage | 128 KB | PQ keys + certs (46 KB) + headroom |
| SRAM for runtime | 128-256 KB | Staves interpreter + layout + framebuffer |
| Flash for firmware | 512 KB - 1 MB | Rust no_std binary + PQ primitives |
| ISA target | RISC-V or ARM Cortex-M | Open (RISC-V) or established (ARM) |
| Power budget | <100 mW total | Rendering + crypto + radio |
| Key rotation | Every 30-60 seconds | 2.2 KB per rotation (negligible) |
QIF Neurosecurity Stack
Runemate and Neurowall are sibling defense components within the QIF framework. Neurowall protects inbound signals (the moat), Runemate protects outbound content rendering (the castle), and NSP secures the wire between them. Both operate at the I0 neural interface bottleneck.
L3 Policy Agent uses the RunematePolicy engine (5-rule priority stack) to dynamically adjust differential privacy epsilon, suppress stimulation, and escalate alerts based on NISS scores and coherence monitor output.
Vision
Project Runemate is not just a compression tool. It is a step toward a neural-native rendering pipeline — a stack where the interface between human and machine is designed from the ground up for the constraints of implanted devices, not retrofitted from desktop browsers.
The Forge (Rust Compiler)
CompleteNative Staves DSL compiler with hand-rolled lexer and recursive descent parser. Multimodal support (visual, auditory, haptic). TARA safety bounds enforced at compile time. Bytecode disassembler for debugging. NSP encryption pipeline with AES-GCM. 24 tests passing.
The Scribe (Neural Runtime)
Next
A no_std Rust runtime for BCI chips. Decodes Staves bytecode and drives cortical stimulation patterns directly. Retinotopic, tonotopic, and somatotopic coordinate transforms map bytecode constructs to cortical electrode positions. Formally verified for memory safety to meet FDA Class III requirements.
Universal Neural Markup
Expansion beyond explicit constructs into direct semantic encoding. Layouts are replaced by perceptual intents mapped through topographic cortical coordinates, making Staves a proposed native language for high-bandwidth neural interfaces.
The Terminal: Patient Control
A sighted person opens a browser. A person with a cortical visual prosthesis needs something fundamentally different — not a browser, but a terminal.
Browsers are rendering engines for screens. They parse HTML, execute JavaScript, composite layers, and paint pixels. None of that maps to electrode arrays on V1. Project Runemate replaces the browser entirely — compiling semantic content directly into electrode-addressable stimulation patterns.
But the interface is not just about rendering. It is about control.
Why no browser or app store
Browsers and app stores are middlemen. Each middleman is an additional layer, and each additional layer is an additional attack surface.
| Layer | What It Adds | What It Risks |
|---|---|---|
| Browser engine | HTML/CSS/JS parsing, V8, compositor | XSS, CSRF, memory corruption, supply chain, extension attacks |
| App store | Distribution, review, payment | Censorship, surveillance, forced updates, vendor lock-in |
| OS window manager | Display server, input routing | Privilege escalation, screen capture, clipboard interception |
None of these layers exist in a neural interface. Project Runemate eliminates all three. Content goes from source to compiler to encrypted bytecode to cortical stimulation. The fewer layers between the user and their experience, the fewer places an attacker can intervene.
Patient self-sovereignty
Right to repair. When a cortical implant IS your visual system, you cannot wait for a manufacturer's scheduled update to fix a rendering artifact. A terminal lets you adjust stimulation parameters, recalibrate electrode mappings, and verify firmware updates.
Right to inspect. Every packet entering your nervous system should be auditable. runemate log --stream is the neural equivalent of tcpdump.
Right to customize. A patient should adjust contrast curves, phosphene brightness, temporal refresh rates, and spatial resolution through direct parameter control — not through a settings menu designed by someone who can see.
Right to disconnect. runemate --offline should work. The device must function without a network connection, without a cloud service, and without phoning home.
Autodidactic navigation. With a terminal, each patient designs their own way of navigating information — based on their preferences and cognitive style, not a prescribed interface. One person might prefer spatial audio cues. Another might use haptic pulses as navigation anchors. A third might develop an interaction pattern no UX designer anticipated. The terminal provides primitives for users to compose their own experience.
Autonomy Guardrails: The Lane-Keep Problem
A car with lane-keep assist nudges you back into your lane. You can override it. A car with full autonomous driving does not ask. Where is the line for a neural interface?
The autonomy spectrum
Levels 1–2 are clearly therapeutic. Level 4 is clearly a violation. The war is fought at Level 3.
The escalation problem
A patient with nerve damage receives a BCI to walk again. Then:
Walk assistance (Motor cortex (M1))
Clear medical need. Measurable physical outcome.
Quit painkillers (Reward circuits, prefrontal)
Crosses from motor to limbic. Same neurons, different territory.
Quit alcohol (Behavioral patterns)
The crutch for walking becomes a governor for decisions.
Run faster than body allows (Motor cortex, exceeding limits)
Overriding fatigue can damage tendons, joints, tissue.
Each step is reasonable in isolation. Together, they are a ramp from assistive tool to autonomous controller.
Ghost in the Shell
If the kernel has immutable rules the patient cannot override, then the patient's consciousness (the ghost) is constrained by a system (the shell) that answers to someone else.
The resolution: the kernel protects the hardware, not the software.
A seatbelt does not control where you drive. It prevents the physics of a crash from killing you. Immutable kernel limits are amplitude ceilings (tissue damage threshold), rate limits (neural refractory period), and thermal bounds (protein denaturation). They do not say "you cannot think that." They say "the signal cannot physically exceed what your tissue can survive."
The five-tier guardrail model
| Tier | Domain | Immutable? | Authority |
|---|---|---|---|
| 1 | Hardware safety | Yes — kernel | Physics/biology. Not negotiable. |
| 2 | Biological safety | Yes — kernel | Clinical evidence. Clinician + patient co-sign. |
| 3 | Therapeutic bounds | Configurable | Clinician sets range. Patient adjusts within it. |
| 4 | Behavioral scope | Consent-gated | Patient decides. Separate consent per domain. |
| 5 | Enhancement limits | Policy layer | Patient + clinician + regulatory. Evolving. |
The five-tier model is proposed within QIF. Specific thresholds (especially Tiers 2–3) are subjects of active neuroscience research. No clinical validation has been performed.
The Steering Argument
If you're not steering the car, you're cargo.
If we don't have free will through consent and agency, then who is driving the car if you're not steering? That is the analogy most people will understand. And it is the design principle behind every layer of this architecture.
AI as tool, not driver
In a neural OS, the user controls AI through methods like subvocalization — thinking commands rather than typing them. The AI processes, suggests, retrieves, compiles, renders. But the decision to act, the consent to a thought becoming an action, the creative impulse that initiates a query or dismisses a suggestion — that is the human.
Without this boundary, AI does not augment human capability. It replaces it. The patient becomes a passenger in their own perceptual system — receiving whatever the algorithm decides to deliver, with no mechanism to inspect, reject, or redirect.
A tool
"Show me what's on this webpage." Patient initiates, AI compiles, Project Runemate delivers. Every interaction begins with patient intent. Every delivery requires patient consent.
A feed
Content streams continuously, selected by an algorithm, with no patient-initiated gate. The user receives. The user does not choose.
Protecting creativity
Creativity requires agency — the ability to combine ideas in unexpected ways, to follow a thought no algorithm would predict, to say "no, show me something else." If the AI drives and the patient rides, creativity dies. Not because AI cannot generate — but because the human loses the muscle of choosing. And a muscle you do not use atrophies.
Neurorights (MP, CL, MI, PC, EA) are the formal expression of this principle. But the terminal is what makes them enforceable. Without a CLI, neurorights are policy. With a CLI, they are access control.
Security Architecture
A neural device cannot use passwords. The patient may not have the motor function to type one. And a password transmitted to an implanted chip is a password that can be intercepted. The security architecture is passwordless by design.
Factor 1: Post-Quantum Key Cryptography
The NSP handshake uses ML-KEM-768 (NIST FIPS 203) for key encapsulation and ML-DSA-65 (NIST FIPS 204) for digital signatures. The device's identity is a hardware-bound keypair provisioned at implantation. No password to remember. No token to carry. No credential to phish.
Patient Device ---- ML-KEM-768 ----> Gateway
| |
'---- ML-DSA-65 signature ---------->|
(hardware-bound key) |
|
<---- Encrypted session key ---------'
(AES-256-GCM-SIV) Factor 2: Biomarker MFA
The second factor is the patient themselves. Neural biomarkers — unique patterns in EEG/ECoG signals that are as individual as fingerprints — provide continuous authentication without any conscious action.
| Biomarker | Signal | Uniqueness |
|---|---|---|
| Resting-state EEG | Alpha rhythm signature (8–13 Hz) | Stable across sessions, unique to individual |
| Evoked potentials | P300/N170 response patterns | Stimulus-locked, difficult to spoof |
| Neural handwriting | Motor cortex activation patterns | Behavioral biometric, continuous |
| Coherence profile | Cross-channel phase synchrony | Structural, tied to individual connectome |
This is continuous, passive verification — not a login ceremony. If biomarker drift exceeds the patient's baseline envelope, the device locks sensitive operations while maintaining basic function. A screen lock, not a shutdown.
Capability-based access control
The terminal does not grant root. Each session, script, and command has explicitly declared capabilities:
# Patient session
capabilities: [perceive.*, config.*, log.read, device.status]
# Clinician session
capabilities: [calibrate.*, log.read, log.export, device.diagnostics]
# Firmware update
capabilities: [firmware.apply]
requires: [device.owner.approval, manufacturer.signature]
No command can exceed its declared capabilities. This is not sudo — it is a capability token system where escalation requires multi-party cryptographic consent.
Neurorights as access control flags
| Neuroright | Flag | Controls |
|---|---|---|
| Mental Privacy | privacy.* | Whether neural data can be read, exported, or shared |
| Cognitive Liberty | liberty.* | Whether stimulation patterns can be externally imposed |
| Mental Integrity | integrity.* | Whether device parameters can be modified without consent |
| Psychological Continuity | continuity.* | Whether changes can alter baseline perceptual experience |
| Equal Access | access.* | Whether content or capabilities can be restricted by provider |
Neurorights as a concept are proposed and under active academic debate (Yuste et al. 2017, Ienca & Andorno 2017). These operational definitions are QIF-specific mappings for threat modeling purposes, not settled legal or philosophical standards.
Neural OS: Linux for the Mind
Project Runemate is the userspace layer of a proposed neural operating system — open-source, auditable, patient-controlled. The architecture maps directly to Linux:
Zero-trust at I0. Amplitude bounds, rate limiting, DoS detection
Encrypted wire protocol. PQ key exchange, session management
Content compilation, rendering, multimodal delivery
Patient CLI. Inspect, configure, script, troubleshoot
MP, CL, MI, PC, EA as capability-based ACL flags
Why open source — the same reasons Linux won
Auditability. Anyone can read the code that runs inside a patient's skull. No black boxes.
No vendor lock-in. A patient's perceptual system should not be tied to a single manufacturer's proprietary stack.
Community security. More eyes on the code means more vulnerabilities found before they reach patients.
Longevity. Implants outlast companies. Open-source code outlasts both.
Right to fork. If the maintainers make decisions a patient disagrees with, the patient (or their advocate) can fork the stack and run their own.
Does the CLI introduce new attack surface?
No. Project Runemate already executes bytecode — the Scribe interpreter processes arbitrary compiled content. A CLI is a structured, capability-gated interface to that same execution engine. It is a subset of what the interpreter already does, constrained by explicit capability tokens.
The Rust no_std runtime eliminates the class of vulnerabilities that make traditional shells dangerous: no buffer overflows (borrow checker), no heap corruption, no shell injection (no exec()). A capability-based shell is strictly less powerful than the bytecode interpreter it sits on top of.
Contribute
Project Runemate is open source under Apache 2.0. The Forge compiler, Staves DSL spec, and all documentation live in the QIF repository.
Repository
github.com/qinnovates/neurosecurity → src/lib/runemate-forgeKey files:
src/— Rust compiler source (lexer, parser, codegen, crypto)STAVES-DSL-SPEC.md— Language specificationSTAVES-SPEC.md— Bytecode format specificationTHREAT-MODEL.md— Security threat modelSTATUS.md— Engineering status and known gaps
Getting Started
1. Clone and build
git clone https://github.com/qinnovates/neurosecurity.git
cd qinnovate/src/lib/runemate-forge
cargo build
cargo test2. Run the demo
cargo run --bin demoCompiles a sample Staves file through the full pipeline: parse → compile → encrypt → decrypt → disassemble.
3. Read the specs
Start with STAVES-DSL-SPEC.md for the language grammar, then STAVES-SPEC.md for the bytecode format. The threat model explains the security constraints driving every design decision.
Where help is needed
Rust / Systems. The no_std runtime (Phase 2) needs a bare-metal bytecode interpreter. If you've worked on embedded Rust, firmware, or RTOS, this is the critical path.
Cryptography. The NSP encryption pipeline uses AES-256-GCM-SIV with the Bellare-Hoang key-commitment transform. Formal security proof of the handshake protocol is the next milestone.
Neuroscience. Validating the retinotopic / tonotopic / somatotopic coordinate transforms against published cortical mapping data.
Security review. Formal analysis of the Staves bytecode format for safety-completeness: can every valid bytecode produce only safe stimulation patterns?
Academic collaboration: This is active research. As this work enters the academic landscape, formal collaboration will further solidify the compiler, safety proofs, and neuroscience foundations. If you're interested in contributing now — or exploring collaboration once institutional frameworks are in place — reach out via GitHub Discussions or open an issue on GitHub.
How Runemate Fits
Runemate is the application layer of a three-part stack:
QIF (Framework) defines what to protect and where the attack surfaces are.
NSP (Protocol) implements the cryptographic wire protocol. The handshake is a fixed one-time cost; every subsequent operation reuses the session.
Runemate (Application) compiles and encrypts neural UIs using the established NSP session — the post-quantum overhead is amortized to zero.
See the full architecture at NSP → How It Fits.