How NexaCore OS is built.

Section 1

The microkernel and its system-call ABI

NexaCore OS runs on a custom microkernel for x86-64, written in Rust and built for the bare-metal target x86_64-unknown-none. The foundational crates are no_std with explicit heap allocation, and the kernel forbids unsafe code outside tightly reviewed boundaries. There is no inherited C runtime.

As of v0.3.0-alpha.1, the kernel boots via UEFI, walks 4-level page tables, isolates each process behind its own address space (per-process CR3), schedules with a per-CPU run queue under a local-APIC timer, and brings up multiple cores — including live AP start-up, cross-CPU context switching, and TLB shootdown. Drivers for NVMe, VirtIO-net, and e1000e run in user space, not in the kernel.

A capability replaces the ambient permission

NexaCore OS does not use Unix-style ambient authority, where any process running as a user can do whatever that user can do. Instead, every privileged action requires a capability token: a signed object that names one action, one resource, and a time window. Capabilities are attenuable (a process can derive a strictly weaker child capability for a task it delegates), revocable (short time-to-live plus a revocation path), and rooted in hardware key material. A process that holds no capability for an action simply cannot perform it.

The ABI is small, and it is frozen

The system-call interface is versioned as a single monotonic integer. Version 1 is frozen: a breaking change requires an explicit, documented proposal and a version bump. The current build implements 58 system calls. They are grouped into the subsystems below.

User-space drivers are loaded through DriverLoad, which verifies a signed package (an Ed25519 manifest signature plus a BLAKE3 image hash) before the kernel mints the narrow capabilities the driver declared — for the exact memory regions and interrupts it needs, and nothing more.

Section 2

AI as a first-class system service

Inference is not an application bolted onto the OS; it is a system service reached through the ABI. Any program can ask the kernel to run a model the same way it asks to read a file, and the request is subject to the same capability checks.

AiInvoke(model_id, input)        -> output
AiStream(model_id, input, chan)  -> session_id   # token-by-token streaming
AiEmbed(model_id, input)         -> embedding: [f64]
AiClassify(model_id, input)      -> label: String
AiTranscribe(model_id, audio)    -> text: String

Every AI call requires the ai.invoke capability. A program with no such grant cannot reach a model at all.

The engine

The runtime ships a from-scratch inference engine: a transformer forward pass with multi-head attention, a SwiGLU feed-forward network, and RMSNorm, paired with a GGUF tensor loader (dequantizing F16/BF16 weights to F32) and a byte-level BPE tokenizer. The full pipeline — tokenize, load, forward, decode — runs inside a Ring 3 user-space service and has been verified on real hardware. A provider layer can also route to local runtimes when present, behind a resilient router.

Why Mixture-of-Experts matters for a mesh

Large NexaCore OS models use a Mixture-of-Experts (MoE) architecture: each layer holds many expert sub-networks, but only the top two are activated for any given token. That sparsity is what makes federation practical — only a small slice of an otherwise huge model is touched per token, so the volume of data crossing the network between nodes stays low. The four execution tiers below trade locality for capacity.

Section 3

Privacy enforced by cryptography, not by policy

The mesh is built on a simple, hard constraint: a node that does not follow the rules cannot produce traffic the rest of the network will accept. Several mechanisms combine to make that true.

The primitives, named

The brand voice of this project forbids phrases like “military-grade”. Instead, here are the actual primitives. Cryptography is drawn from the audited RustCrypto family: Ed25519 for signatures, X25519 for key agreement, ChaCha20-Poly1305 for authenticated encryption, BLAKE3 and SHA-2 for hashing, and Argon2 for password hashing. Mesh transport is planned on QUIC with the Noise protocol framework. Format-preserving encryption uses the NIST FF1/FF3-1 constructions.

Section 4

ncScript — a language designed to run untrusted code safely

ncScript is NexaCore OS's scripting language: a small, Rust-flavoured language whose interpreter is a no_std library with zero production dependencies, building for both the host and the bare-metal kernel target. The pipeline is conventional — lexer, parser, abstract syntax tree, tree-walking interpreter — but two properties make it unusual: every effect is denied by default until a capability grants it, and every run executes under deterministic resource limits. The verified examples below are taken directly from the interpreter's own test suite.

Try it: a guided tutorial

A guided, in-browser tutorial — thirteen short lessons, each one runnable and editable. Step through with Prev / Next, change the code, and Run. Everything executes on your machine; the capability gate and the step budget are real.

The smallest program

Every program has a main function. print is built in and always available — it needs no capability, because writing to the script's own output buffer is not a system effect.

fn main() {
    print("Hello, world");
}

Familiar syntax

Functions, let/mut bindings, expressions-as-values, and recursion behave the way a Rust or Swift reader expects.

fn fib(n) {
    if n < 2 { n } else { fib(n - 1) + fib(n - 2) }
}

fn main() {
    fib(10)        // => 55
}

Collections, loops, and structs

fn main() {
    let mut sum = 0;
    for x in [1, 2, 3, 4] {
        sum = sum + x;
    }
    sum            // => 10
}

struct P { x: Int, y: Int }

fn main() {
    let p = P { x: 3, y: 4 };
    p.x + p.y      // => 7
}

Pattern matching, Result, and the ? operator

Errors are values. match supports or-patterns and guards; the ? operator propagates an Err and returns early, exactly as in Rust.

fn classify(n) {
    match n {
        0 | 1      => 100,    // or-pattern
        p if p < 0 => -1,     // guard
        p          => p
    }
}

fn get(ok) {
    if ok { Ok(7) } else { Err(42) }
}

fn use_it(ok) {
    let v = get(ok)?;   // `?` propagates Err
    Ok(v + 1)
}

fn main() {
    match use_it(true) {
        Ok(x)  => x,        // => 8
        Err(e) => e
    }
}

Deny-by-default capabilities

This is the heart of the language. A script declares, in its header, exactly which system effects it intends to use. Anything it does not declare, it cannot do. A script with no declared capabilities is pure computation: it can calculate, but it cannot touch the filesystem, the network, or a model. Capability scopes are hierarchical — a grant for /etc/nexacore covers /etc/nexacore/notes/a.txt but rejects /etc/passwd — and the check runs before any input/output happens.

// Capabilities are declared in the script header.
// Deny-by-default: an effect not listed here cannot run.
#![capabilities(fs.read("/etc/nexacore"), ai.invoke)]

fn main() {
    // `fs::read` is a host effect, gated by the `fs.read` capability.
    // Scope "/etc/nexacore" admits this path and would reject "/etc/passwd",
    // and the decision is made before any byte is read.
    let notes = fs::read("/etc/nexacore/notes/a.txt");
    print(notes);
}

A subtle but important guarantee: if no host effect handler is installed, a call like net::connect("x") is not an error and is not I/O — it is inert data. The language has no ambient access to the outside world. Effects exist only where the host explicitly provides them, gated by a capability the script explicitly requested.

A pure standard library

The bundled standard library is deliberately effect-free. The string module (and a math module) perform pure computation only, so they are always safe to call regardless of capabilities.

fn main() {
    let parts = string::split("a,b,c", ",");  // ["a", "b", "c"]
    let n     = string::len("héllo");         // 5 — counts characters
    let up    = string::upper("nexacore");        // "NexaCore"
    print(string::from_int(parts.len()));   // prints "3"
}

Deterministic resource limits

The host embeds the interpreter and hands it a budget. The interpreter counts instructions, tracks live memory, watches an injected clock, and bounds call depth — so an infinite loop, a memory bomb, or runaway recursion ends cleanly with a typed error instead of taking the host down. Limits are deterministic, which means the same script and budget behave identically every run.

// Host side (Rust): every script runs under a hard, deterministic budget.
let limits = Limits {
    max_steps:       Some(1_000_000),  // instruction budget — stops infinite loops
    max_alloc_bytes: Some(64_000),     // live-memory ceiling
    deadline_micros: Some(5_000_000),  // wall-clock deadline (injected clock)
    max_call_depth:  Some(64),         // recursion guard — no host stack overflow
};

let (value, output) = run_with_limits(src, limits)?;

A module system resolves use a::b imports across scripts, checks that the imported symbol is actually exported, orders modules so dependencies load first, and rejects import cycles — all before execution begins.

Delegating to the built-in agents

NexaCore OS ships five specialised system agents — an Orchestrator, a Guidance agent, a System Administrator, a Security & Performance agent, and a Task agent. A script does not command them directly; it states an intent through a declared capability, and the Orchestrator routes the work to the right agent under the Security agent's watch. The binding that exposes this to ncScript is on the roadmap; the snippet below is illustrative of its intended shape, not yet a running test.

// The `agent.task` capability lets this script delegate a goal.
// The Orchestrator dispatches it; the Security agent screens it.
#![capabilities(agent.task)]

fn main() {
    let summary = agent::task("summarise today's files in ~/reports");
    print(summary);
}

Read about the five built-in agents →

Section 5

Stack and versioning

Language

Rust, 2024 edition (minimum supported compiler 1.85)

Kernel target

x86_64-unknown-none, no_std, bare-metal UEFI boot

Cryptography

RustCrypto family — ed25519-dalek, x25519-dalek, chacha20poly1305, sha2, blake3, argon2

Serialization

postcard as the canonical internal wire format (a compact, no_std format)

Mesh transport

Planned on QUIC (quinn) with the Noise framework (snow)

Compliance proofs

STARK proof system (transparent setup, post-quantum sound)

Trusted hardware

Intel TDX, AMD SEV-SNP at launch; Apple Secure Enclave and ARMv9 CCA planned

Versioning

Semantic Versioning for the OS; the system-call ABI carries its own monotonic version (v1, frozen); the mesh protocol negotiates its version at handshake

License

Open source — see the repository LICENSE

Section 6

Implementation state

NexaCore OS is in Phase 1 (microkernel proof of concept), with Phase 2 (AI runtime) advancing in parallel. The table records what is implemented versus scaffolded as of v0.3.0-alpha.1.

Stability of design comes before speed of delivery.

The full backlog and the design documents behind each decision live in the project's documentation set. The visual and verbal identity used across this site follows the project's brand pack.

← Back to the overview