3 System Architecture Overview¶

Client API
↓ Executive Controller / Router / Planner Layer
↓ Memory Governor + Grounding Selection
↓ Execution Contract + EIS Policy Selection
↓ Execution Nodes
├── Semantic Core
├── Role-Based Expert Models
├── Domain-Specific Expert Models
├── Capability-Driven Expert Processing
└── Tool-Support / Verification Services
↓ Verification / Arbitration / Synthesis
↓ Reputation-Weighted Consensus
↓ Grokipedia Grounding & Private Knowledge Validation
↓ Final Response
↓ Qualified Cognitive Events
↓ GAML / VTG / Routing / Arbitration / EGGROLL Adaptation Paths

The RuntimeCoordinator owns the request lifecycle and the coordination of qualified post-execution events. Cognitive evolution is not a separate runtime: it routes policy-approved Cognitive Assets and outcome signals to the existing memory, transition, policy, benchmark, and retraining subsystems through the shared contracts defined in Cognitive Evolution Coordination.

The specialist layer uses Expert Model (EM) as the neutral umbrella term. Expert execution is described across separate dimensions: cognitive role, public contract/capability, processor architecture, and execution backend. ELM — Expert Language Model denotes a language-generation/transformation contract, while EJM — Expert Judgment Model denotes bounded typed judgment. Diffusion is a processor architecture rather than a mutually exclusive contract; an EDM — Expert Diffusion Model is shorthand for a diffusion-backed implementation and may also expose the EJM contract when used for structured judgment.

GQHSM-compatible hierarchical state machines may coordinate expert-stage lifecycle and processor dispatch through data-driven states, guards, events, and registered callbacks. The state machine owns orchestration semantics such as selection, fallback, verification, and escalation; it resolves the required capability first, then allows the processor registry to choose a compatible autoregressive, diffusion, encoder, multimodal, local, or distributed implementation. It does not own model-specific generation, selected-logit evaluation, diffusion loops, KV-cache internals, or tensor execution.

EIS verification is normally sampled and asynchronous rather than a blocking step in the interactive inference path. The execution contract is selected before dispatch, while EIS validates execution integrity through claims, spot-checks, and reputation evidence outside semantic answer scoring.

4 GNUS Component Mapping¶

4.1 Compute Layer¶

The Compute Layer handles the hardware-level execution and optimization of the Semantic Core and expert modules on GNUS nodes, ensuring high-throughput and energy-efficient inference in line with the system's primary goals.

MNN: Model runtime
This serves as the optimized deep learning inference engine responsible for executing the Semantic Core and expert modules efficiently on the diverse hardware found across the GNUS network.
Vulkan / MoltenVK: GPU acceleration
These components provide GPU acceleration for inference operations. Vulkan is the cross-platform standard, while MoltenVK specifically enables Vulkan compatibility on Apple platforms, ensuring wide hardware reach.
SGFP4 codec: Weight compression
This component manages weight compression via the SGFP4 adaptive format, directly enabling efficient low-bit deployment of the Semantic Core and selected expert modules.
CUDA/Vulkan shaders: Tile-based decode & matmul
These are leveraged for high-performance, optimized numerical operations, specifically for tile-based decode and matrix multiplication of compressed weights during runtime.
Execution Integrity System (EIS): Execution-contract verification
EIS validates that distributed compute providers execute the declared model, adapter, SGFP4 container, kernel manifest, determinism class, sampling seed, and execution profile. It is concerned with execution honesty rather than semantic answer quality.

4.1.1 SGFP4 Design¶

The custom quantization uses the SGFP4 adaptive format, designed for minimal overhead and maximum efficiency across diverse GPU hardware. Full details are in 22 SGFP4 Adaptive Quantization Format.

Key properties:

Two profiles: a v1 fixed-payload profile (64x64 macroblocks, fixed 2048-byte payload per block, uniform GPU addressing) and a v2 quadtree-adaptive profile (self-framed 'SGF4' stream; macroblocks split into 64x64–4x4 leaves by error, spending bits only where needed).
Per-block/leaf scale + bias (affine decode: w_hat = S * code + Bias) stored as packed FP16 in a single uint32 header.
Adaptive dual-mode: FP4_AFFINE (4-bit signed codes) or T158_AFFINE (ternary codes in ~1.58-bit class) per block/leaf, selected by the encoder via Laplacian-weighted error minimization.
Flags-in-offsets (v1) / flags-in-headers (v2): Mode selection is embedded in the low 4 bits of aligned payload offsets or leaf headers — zero additional memory cost.
Normative decode semantics: independent decoders produce bit-identical tensors, making container decode a contract-grade artifact for the Execution Integrity System.
Compressed weights are decoded in shared memory at inference time by GPU compute shaders with per-workgroup branching.

The Semantic Core is expected to be the primary beneficiary of aggressive compression, while role-based and domain-specific experts may use different quantization tradeoffs depending on whether they optimize for breadth, language generation, bounded judgment quality, deterministic formatting, diffusion/refinement stability, verification quality, or workflow specialization.

4.2 Distributed Layer¶

The Distributed Layer is fundamental to operating GeniusCognitiveSystem as a decentralized cognitive system across GNUS nodes. It utilizes specialized technologies to manage communication, data transfer, memory convergence, task coordination, and execution-integrity evidence.

libp2p: This is used for task broadcast, distributed coordination, and result aggregation. It handles propagation of execution plans from the orchestration layer to participating nodes and the subsequent collection of expert results for verification, arbitration, and reputation-weighted consensus.
IPFS-lite: The system relies on IPFS-lite for model and artifact distribution, ensuring that the Semantic Core, expert modules, manifests, and supporting assets are efficiently available to participating nodes.
RocksDB: Serves as the component for local caching and structured memory support. It is used for general-purpose local storage and for maintaining local copies of memory objects, indexes, execution claims, verification evidence, reputation data, qualified cognitive events, and adaptive artifact metadata.
CRDTs: These Conflict-free Replicated Data Types are critical for reputation synchronization and memory convergence. They are used to replicate selected state across the distributed network while preserving consistency under concurrent updates.
gRPC: This functions as a primary API and service interface, providing the mechanism for external clients and internal services to interact with the system.

4.2.1 Layered Cognitive Stack¶

The broader cognitive stack is organized into the following layers:

Client and API Layer — session lifecycle, authentication, request submission, policy attachment, and response delivery.
Orchestration Layer — router, planner, RuntimeCoordinator, optional GQHSM-compatible state-machine definitions, memory governor, execution mode selector, EIS policy selector, policy evaluator, task decomposition logic, and cognitive evolution coordination.
Expert Execution Layer — Semantic Core plus role-based and domain-specific Expert Models. Public contracts include ELM language generation and EJM bounded judgment; processor architectures such as autoregressive and diffusion implement those contracts and bounded refinement/infill through local or distributed model-processing services.
Execution Integrity Layer — execution contracts, determinism classes, kernel manifests, checkpoint-band calibration, teacher-forced spot-checks, and fraud verdicts.
Consensus and Grounding Layer — reputation-weighted consensus, verification, critique, arbitration, Grokipedia integration, and private knowledge grounding.
Security and Tool Intermediary Layer — dry-run, sanitization, permission checks, approval gates, and execution attestations.
Memory and Cognitive Asset Layer — GAML-based structured memory, bridge blocks, facts, policies, retrieval pipelines, qualified cognitive events, EIS evidence assets, and CRDT-backed replication.
Distributed Infrastructure Layer — messaging, discovery, storage propagation, scheduling, health monitoring, and settlement integration.

ELM and EJM are public contract labels, while diffusion/autoregressive/encoder/multimodal are processor-architecture labels. They do not form separate top-level architectural layers. A diffusion-backed Verifier may expose the EJM contract; a diffusion-backed Formatter may expose REFINE/INFILL; one artifact may expose both. EJM probability and uncertainty outputs may inform routing, verification, arbitration, capability selection, and escalation, while deterministic services retain authority over policy, permissions, privacy, and side effects. Refinement output remains provisional until the configured verifier accepts it.

4.3 Security Layer¶

The 4.3 Security Layer is designed to establish trust, ensure data integrity, and protect communication and execution boundaries across the decentralized network.

libsecp256k1: Node Identity
This elliptic curve digital signature algorithm is foundational for establishing unique identities of GNUS nodes, which is a prerequisite for participation, attestation, and reputation-weighted coordination.
ed25519: Message Signing
A high-speed, secure public-key signature system is employed for message signing across the network. This ensures the authenticity and integrity of inter-node communications, such as plan distribution, expert result submission, tool attestations, execution claims, adaptive event records, and finalization records.
OpenSSL: Secure Transport
The system relies on OpenSSL to provide secure, encrypted transport layers (TLS/SSL) for network communication. This protects data in transit between the Client API, orchestration services, and execution nodes.
wallet-core: Reputation and secure state storage
This component is used for secure and robust storage of reputation-related data and other persistent trust state required by distributed task execution.
Tool Intermediary boundary:
Secure agent execution requires a mandatory intermediary choke-point between expert reasoning and real-world side effects. This boundary enforces deterministic dry-runs, sanitization, capability checks, approvals, and tool attestations before any side effect is allowed.

4.3.1 Core Architectural Distinction¶

The system is built around three main execution and reasoning classes:

Semantic Core — a broadly capable reasoning substrate responsible for general understanding, synthesis, and default response generation.
Expert Models (EMs) — narrower specialized units invoked for additional expertise, verification, structure, grounding, bounded judgment, refinement, or action support. ELM and EJM identify public contracts; autoregressive, diffusion, encoder, reranker, and multimodal identify processor architectures that may implement one or more of those contracts.
Execution Integrity System (EIS) — the integrity subsystem that verifies execution contracts and detects model, adapter, kernel, quantization, or sampling substitution.

This distinction is foundational. GNUS.ai does not assume that every task should be solved by a single general-purpose model, that every expert must generate language, or that semantic consensus alone is sufficient to prove that the declared computation was honestly executed.