SigmaNex® Protocol.
Technical Whitepaper

1. Preface: The Enclosure of Intelligence

In the 21st century, cognitive labor is being rapidly outsourced to algorithmic systems. However, unlike the engines of the Industrial Revolution — which could be owned outright by the firms that deployed them — the engines of the Cognitive Revolution are provided as rentable services. Access to intelligence is a subscription, not a possession.

This model introduces a structural fragility with no modern precedent. Historical analogies are instructive: the deliberate severance of internet infrastructure in Syria (2011), Myanmar (2021), and Iran (2022) left populations cognitively isolated precisely when access to verified medical, legal, and coordination information was most critical. In each case, cloud-dependent services failed simultaneously and completely. Local knowledge did not.

The threat is not purely geopolitical. Solar electromagnetic pulse events (EMP), large-scale undersea cable failures, and cascading grid outages all present the same failure mode: the wholesale disappearance of externally-hosted intelligence resources at the moment of highest demand. A single fiber cut in the Mediterranean in 2008 disrupted internet access for over 70 million people across five countries.

SigmaNex® starts from a different axiom: Intelligence is not a service — it is infrastructure. And like all critical infrastructure, it must survive the collapse of the grid that normally delivers it.

This project is not a prepper product. It is a serious engineering response to a well-documented systemic risk. The SigmaNex architecture is designed to be as useful to a field medic in a disaster zone as it is to a privacy researcher operating under state surveillance. The threat model is broad; the solution is deliberately sovereign.

2. Technical Architecture

2.1 The Inference Kernel

The core inference engine is built on llama.cpp — a portable, C++ inference runtime with no external library dependencies. It implements matrix multiplication through CPU-native SIMD instruction sets, enabling viable token generation rates on commodity silicon without cloud servers, GPUs, or specialized NPU hardware.

The kernel is compiled with platform-specific optimization flags, automatically selecting the highest available instruction set at boot time. On a modern Intel Core i7 with AVX-512 support, a quantized 13B parameter model achieves 8–12 tokens per second — sufficient for real-time interaction. The following benchmarks represent measured performance on target hardware configurations:

Target deployment profile: Mistral 7B Q5_K_M on a standard consumer laptop (≥16 GB RAM). This configuration delivers real-time responses with a 9 GB memory footprint, leaving headroom for the OS, the RAG engine, and the mesh radio daemon.

2.2 The Persistence Layer: Zero-Trace

The SigmaNex OS boots from a USB drive into a read-only SquashFS root filesystem. All runtime modifications to system state — temporary files, session logs, process sockets — are written to a tmpfs RAM overlay (OverlayFS) mounted over the read-only base. These modifications exist exclusively in volatile RAM and vanish the instant power is removed. The host machine's storage is never touched.

For data that must persist across sessions (user-annotated medical records, tactical map overlays, offline correspondence), SigmaNex provides a dedicated encrypted partition on the USB drive itself, protected by AES-256-XTS (LUKS2 container). The decryption passphrase is never stored anywhere — it is derived at runtime from a user-provided secret via Argon2id key derivation (memory-hard, side-channel resistant).

On a controlled shutdown, before the OverlayFS is unmounted, the kernel triggers a secure RAM scrub routine that overwrites volatile memory with pseudorandom bytes — preventing cold-boot memory imaging attacks on hardware that may be subsequently confiscated.

• —No Registry Writes: The bootloader uses UEFI Secure Boot paths and writes no entries to the host EFI partition or Windows Registry.
• —No Pagefile / Swap: Swap is disabled at the kernel level. RAM contents are never serialized to non-volatile storage.
• —No Persistent Logs: Systemd journal is redirected to tmpfs. All logs survive only for the duration of the session.
• —Sovereign Air-Gap: All global IP routing (default gateway, DNS resolvers) is disabled at network initialization. The radio mesh interface operates on a private, non-routable subnet.

2.3 Memory & Quantization Strategy

Raw LLM weights in 16-bit (BF16) floating-point are impractical for USB deployment: a 13B parameter model occupies ~26 GB. The GGUF format — native to llama.cpp — implements block-wise quantization schemes that dramatically reduce storage and RAM footprint with measurable but operationally acceptable quality degradation. The following table details the primary quantization targets used in SigmaNex image builds:

The "K_M" suffix denotes the "K-quant" method with medium-scale calibration, which applies higher precision to attention and feed-forward layers that carry the highest information density, while aggressively quantizing embedding and normalization layers. This asymmetric approach recovers approximately 0.8% perplexity relative to uniform quantization at the same bit depth.

Warning: Models quantized below Q4_K_M show measurable degradation on medical and technical reasoning tasks — the exact domains where SigmaNex is most likely to be deployed. Q5_K_M is the minimum acceptable quantization for operational use.

3. Formal Threat Model

SigmaNex operates in adversarial physical and digital environments. The threat model is explicit: we identify the protected assets, the threat actors, the attack vectors, and the architectural mitigations. Security is never achieved by policy alone — every guarantee listed below is enforced by architecture.

Out of scope: SigmaNex does not protect against a fully compromised host firmware (UEFI rootkit) or an adversary with physical access to RAM during an active session. These attack vectors require hardware-level tamper protection beyond the scope of a software-defined system.

4. Knowledge Assurance: Static RAG

A disconnected AI cannot retrieve current information from the web. In its absence, a raw LLM is prone to "hallucination" — the confident generation of plausible but factually incorrect content. In medical or engineering contexts, this failure mode is not a UX problem — it is a life-safety risk. SigmaNex addresses this with a Static Retrieval-Augmented Generation (RAG) pipeline that grounds all model responses in a curated, verified, offline knowledge corpus.

At build time, the reference corpus is chunked into 512-token segments with a 64-token overlap window and embedded using BAAI/bge-small-en-v1.5 — a 33M parameter embedding model optimized for CPU inference (~40ms per chunk). The resulting vectors are indexed in a FAISS flat-L2 index stored on the USB partition. The index is read-only and cryptographically signed — any tampering with the knowledge base is detected before the session begins.

At inference time, the user's query is embedded by the same model, and the top-k (k=5) most semantically similar chunks are retrieved and prepended to the system prompt as verified context. The model is instructed via a hardcoded system directive to answer only from the provided context and to explicitly state when its knowledge base does not contain relevant information rather than speculating.

The corpus is designed to expand. Verified supporters have access to the build pipeline and can submit additional corpus documents for review. All documents undergo a provenance verification step before inclusion: source, edition, license, and a manual accuracy review by the engineering team.

5. The SigmaNex Communication Protocol: Sovereign Intranet

A common misconception equates "networking" with connection to the World Wide Web. SigmaNex rejects this conflation. Our communication layer is an extension of the air-gap philosophy: we do not connect to the internet — we give you the architecture to build your own impenetrable, sovereign intranet.

The radio layer is based on LoRa (Long Range) — a chirp-spread-spectrum modulation technique designed for maximum range and penetration at the cost of raw bandwidth. This is a deliberate choice. SigmaNex nodes do not stream audio or video — they transmit encrypted JSON payloads (AI queries, telemetry, map pins, text messages) that are typically under 512 bytes. LoRa is precisely engineered for this use case.

The mesh uses a flooding architecture with adaptive TTL: each node retransmits received packets with a decremented Time-To-Live counter, ensuring that messages reach all reachable nodes within the mesh without central routing coordination. When a node fails or is removed, the network self-heals — no re-routing tables to update, no single point of failure.

6. Cryptographic Stack

Cryptographic guarantees in SigmaNex are not optional features — they are the architecture. Every data boundary in the system (storage, memory, radio transmission) is protected by a distinct, purpose-selected primitive. There is no single cryptographic "mode" — each layer uses the algorithm best suited to its threat model and performance constraints.

AES-128-CTR is used for radio payloads (rather than AES-256) because LoRa frames have a 255-byte maximum payload. The overhead of a 256-bit key schedule in CTR mode exceeds the marginal security benefit at these payload sizes — 128-bit AES provides 2¹²⁸ security, which is computationally infeasible to brute-force for any foreseeable threat actor.

All cryptographic primitives are drawn from established, audited libraries (libargon2, mbedTLS). No custom cryptographic algorithms are implemented. This is a deliberate security policy: cryptographic primitives are not designed in-house.

7. Governance & Roadmap

SigmaNex is developed under a Supporter-First model: there is no venture capital, no institutional funding, and no corporate governance. The development is led by Lead Engineer Martin Adrian Sebastian. Verified financial supporters gain auditable access to security-critical source modules throughout the development lifecycle — before any public release.

This is not open-source software. The Supporter-First model is a deliberate compromise between full transparency (which creates supply-chain attack surface before the code is hardened) and full opacity (which prevents the community trust that security-critical tools require). Supporters function as a distributed security review layer.