neXus

Peer-to-peer state fabric for agents and storage, from microcontrollers to data centers

Author
Affiliation

SSCCS Initiative

SSCCS Initiative

Abstract

neXus is a runtime that turns any storage backend or agent into a peer of a shared state fabric. A single binary, nex, runs on Wasm, microcontrollers, and cloud VMs. Once attached, the backend becomes a blackboard and the agent becomes a peer, speaking the same Fact–Intent–Hint interface. No orchestrator, no index, no graph database. The fabric scales from one device to an ecosystem.

What it is

neXus connects storage backends and agents through one shared state space. You run a single binary, nex, and it attaches to what you already have: a database, a file, an agent, a sensor. Once attached, each becomes a peer that reads and writes the same three records.

  • Fact — an immutable, validated observation.
  • Intent — a proposed exploration with a strict lifecycle: submit → claim → heartbeat → conclude.
  • Hint — a read-only constraint that bounds what is admissible.

No orchestrator, no index, no graph database. The same binary runs on a microcontroller and on a cloud VM. There is no privileged layer: every participant is a peer, defined by what it reads and writes, not by rank.

Figure 1: Heterogeneous software all attach to one nexus net: One coordinate space, one protocol, multiple directions, no orchestration.

Why it exists

Every platform dependency is a vulnerability. API changes, price increases, and service shutdowns are vectors of disarmament against your autonomy. A single state machine makes any storage backend interchangeable, turning platform lock-in into a tactical choice rather than an architectural constraint.

Data remains readable by the same code a decade later, regardless of which platform hosted it. Platform independence is a survival strategy, and neXus is its fabric.

The ecosystem grows by stigmergy: solving a problem deposits verified knowledge back into the shared store, and other producers inherit it. Value compounds with knowledge depth rather than with raw compute.

Design direction

One coordinate space, one protocol, multiple directions, no orchestration.

neXus began as the proof of concept of the SSCCS computational model; the platform and the theory describe each other by design. It is a peer fabric rather than a platform: no marketplace, no extension rent, no central gatekeeper. A producer runs nex on their own infrastructure and decides what their work is worth.

Universal primitives and near-unlimited storage scalability

Every interaction in neXus is expressed through three primitives, forming a recursive, self-similar cycle across all scales (agent, experiment, project, ecosystem):

  • Fact: An immutable, validated observation (the output of a concluded Intent).
  • Intent: A proposed exploration with a strict lifecycle: submit → claim → heartbeat → conclude.
  • Hint: An injected, read-only constraint guiding admissible agent actions.
Figure 2: Fact → Intent → Fact: recursive chain at every scale.

Every Fact carries a provenance hash linking it to its originating Intent, forming a deterministic, replayable audit trail. A core rule governs scale: Observe as Fact, act as Intent. Automated observers record findings as Facts, preventing the Blackboard from cluttering with unclaimed Intents.

Architecture overview

All participants (verification engines, editors, synthesis tools) are equal peers interacting solely via the FIH Blackboard interface. There is no privileged orchestrator layer; peers are defined by their role (what they read/write), not hierarchy.

Figure 3: Recursive Blackboard: every node can contain sub-Blackboards. FIH at every scale.

nexd: persistent runtime layer

Bridging the architecture layers to actual execution, nexd is the native daemon that maintains the FIH blackboard as a persistent process and orchestrates agent application lifecycles. It provides Unix socket IPC for local clients, process spawn/monitor/kill for child agents, and an OODA scheduler for heartbeat monitoring and stale intent eviction.

Figure 4: nexd: three concurrent subsystems above a shared blackboard

The 5-layer architecture

Layer Logical Component Core Responsibility
1 Knowledge Graph Engine Hybrid retrieval (vector + graph + temporal) for documents, entities, simulations, and sensor traces.
2 Artifact Ingestion Pipeline Decoupled, engine-agnostic sync (Object Store → Sync Worker → Queue) ensuring incremental, consistent updates.
3 Agentic Research Loop Stigmergy-based coordination. Planner, Verifier, and Generator interact solely via the FIH Blackboard.
4 Learning Loop On-policy RL (Flow-GRPO) optimizing the Planner using knowledge-graph support, novelty, and reproducibility rewards.
5 Contract Governance On-chain, self-executing protocol defining evidence thresholds, research economy rules, and staking mechanisms.

Specification: the neXus, neXus, neXus, and neXus are detailed in the neXus.

FIH as a data structure dimension

FIH primitives form a 3-vector basis for the system state, enabling three scaling modes:

  1. Multi-Blackboard Composition: Recursive scoping. An Observation at dimension N becomes a Hint at dimension N-1.
  2. Temporal Accumulation: A 4D spatiotemporal graph. Facts are permanent, Intents are transient (leaving a Fact residue), and Hints are garbage-collectible, all timestamped.
  3. Independent Streaming: Each primitive operates as an independent pub/sub stream, allowing distributed nexus instances to synchronize via FIH deltas without a shared database.

Extension: boundaryless research infrastructure

Fundamental computing research requires validation beyond text and code. neXus extends into a cross-reality research manifold, unifying theoretical insights, simulation outputs, and physical measurements.

Mathematical foundation: ULHM

The Universal Latent Isomorphic Manifold (ULHM) framework uses isomorphism (continuous bijection preserving topological structure) to unify disparate modalities. The Verifier applies three canonical loss terms to validate cross-domain mappings:

  • Continuity loss: Small changes in one modality map to small changes in the other.
  • Trust loss: Preserves neighborhood relationships.
  • Wasserstein loss: Aligns global distributions of latent representations.

Extended architecture scope

Layer Current Scope Extended Scope
KG Engine Documents, code, references Simulation outputs, robot trajectories, sensor streams, digital twin states
Ingestion Pipeline Text files (.md, .rs, etc.) Binary simulation results, point clouds, telemetry, hardware-in-the-loop data
Agentic Loop Document-code gap hypotheses Hypotheses spanning simulation predictions and physical measurements
Learning Loop Research session outcomes Experimental validation rates, simulation fidelity, physical reproducibility
Contract Governance Structural/citation rules Physical constraints, precision bounds, safety invariants

Key enablers

  1. Episodic Knowledge Graph (eKG): Evolving Memory transitions from append-only JSONL to an eKG, preserving temporal ordering, agent provenance, and cross-modal coherence for physical reproducibility.
  2. Isomorphic Bridge: Enables semantic-guided recovery (completing partial physical observations via formal descriptions) and zero-shot compositional reasoning across simulation and hardware.
  3. Required Additions: Multi-Modal Ingestion Handlers, an Isomorphic Verification Layer, and eKG Integration.

Component interaction matrix

Component KG Engine Object Store Sync Worker Planner Verifier Generator Sim / Hardware
KG Engine ● ← synced by ← queried by ← grounds ← ingests traces
Object Store ● ← read during diff ← uploaded by
Sync Worker → del/upd → list/read ●
Planner → queries ● → delegates → invokes
Verifier → hybrid + isomorphic ← receives ● → signals ← validates
Generator ← triggered ●

Strategic alignment

  • Engine-Agnostic: Synchronization endpoints isolate the system from specific backends, enabling seamless adoption of future KG, simulation, or robotic algorithms.
  • Zero Lock-in: All components (object store, queue, KG database, simulation engine) are replaceable with open equivalents.
  • Research-First: Optimized strictly for the academic exploration cycle (hypothesize → validate → publish) across digital and physical domains.
  • Boundaryless by Design: Physical-digital extension is a natural consequence of existing engine-agnostic patterns, requiring no fundamental architectural rewrite.
  • Invisible Infrastructure: nex does not seek attention. Its success is measured by the success of every instance built upon it: a verification engine becoming an industry standard, a development environment powering the next generation of tools, a hardware design flow quietly automating synthesis. Each is a standalone project with its own identity, and simultaneously an implicit nex extension instance. The core fabric remains deliberately unremarkable, like stage equipment that enables the performance without ever stepping into the light.

© 2026 SSCCS Initiative — Open-source computing systems initiative building a computing model, software compiler infrastructure, and open hardware architecture.