Apps Ecosystem

neXus entity ecosystem driven by composite nex instances

Author
Affiliation

SSCCS Foundation

SSCCS Foundation

Published

June 4, 2026

Code

Github

References

neXus

Other Formats

LLMs

Introduction

nex is a lightweight runtime binary or library processing core with an embedded blackboard protocol that doubles as its memory, and a built-in specification for permanent storage backends. Each nex-{app} instance is a self-contained binary that reads and writes Facts, Intents, and Hints through this internal blackboard, performing domain-specific tasks without central coordination. Any domain engine can be wrapped as a nex-{app} by implementing the runtime interface, gaining blackboard memory, stigmergic coordination, and cryptographic signing without external infrastructure.

Core Principles

  • Infrastructure, not product – nex is invisible as an internal neXus entity.
  • Built-in memory – the FIH blackboard protocol serves as the runtime’s native memory; no external database required.
  • Embedded storage spec – a permanent storage backend (filesystem, SQLite, cloud, blockchain) plugs in via a defined specification, decoupled from processing.
  • Stigmergy – Agents leave traces on the blackboard; other agents react indirectly, without orchestration.
  • Recursive self-similarity – A single nex mirrors the whole neXus network. The same thin kernel composes fractally: an atomic nex embeds its own blackboard; multiple nex instances form a cluster sharing a logical blackboard; clusters federate into larger structures.
  • Immutable facts – All knowledge is content-addressed and tamper-proof (e.g. C2PA signatures).

Composition Model

Your Codebase + nex core library integration = nex-{app}

The nex kernel provides the blackboard as built-in memory, FIH protocol handling, stigmergic coordination, and cryptographic signing — all within the binary. A permanent storage backend (filesystem, SQLite, cloud, blockchain) plugs into the kernel via the storage spec, decoupled from processing. For example, ExaVerif is an independent project that also functions as a nex instance (nex-ev) by grafting the domain engine onto the runtime.

Example Cases

Every nex-* instance shares the same blackboard schema and communication protocol. They are designed to be launched and supervised by the neXus runtime.

Instance Domain Role
nex-zed Development Agentic editor extension for Zed – browses blackboard, spawns verification branches.
nex-phys Robotics Connects to physical simulation (Gazebo, MuJoCo) or real hardware; feeds sensor data as Facts.
nex-rtl Hardware Design Generates synthesizable RTL (Verilog/SystemVerilog) from high‑level Intent and past Facts/Hints.
nex-lk Self-Security Monitors blackboard for malicious Facts/Intent, isolates compromised branches.
nex-veridb Knowledge Aggregates public RISC‑V / RTL verification facts (GitHub, papers) into the blackboard.
nex-bio Computational Biology Models protein folding, cell signalling, neural circuits as Fact graphs.

Cross-Language Bindings

The nex runtime is written in Rust and exports a stable C ABI. It also supports WebAssembly (WASM) as a universal compilation target. This enables any language that can call C functions or emit WASM to become a first-class nex agent.

Language Binding Mechanism Status
Rust Native – implement neXAgent trait directly Core
C / C++ C ABI – expose neX_agent_* functions Planned
Python PyO3 / ctypes – wrap Rust core Prototype
Node.js / JavaScript napi-rs / node-bindgen Planned
Go, Zig, Nim C ABI or WASM Future

Storage Architecture

Three Storage Primitives

The nex runtime defines three storage primitives as pure-sync interfaces. Zero async dependency, zero platform-specific code. Any backend that satisfies the contract plugs in without changing core logic.

Primitive Interface Purpose
KV Storage read / write / delete / list String-keyed storage for Facts and Hints
Blob Storage put / get / delete / list Arbitrary byte storage for archived Fact streams, C2PA provenance bundles
Object Storage read-state / compare-and-swap Strongly consistent CAS for Intent arbitration

A storage orchestration layer binds all three tiers, managing flush cursors, FIH persistence, and time-range queries. Every storage backend — filesystem, SQLite, cloud object storage, blockchain — conforms to the same three-primitive contract.

AsyncStorage Bridge

When the storage backend lives across an async boundary (network, cloud API, WASM runtime), the nex core remains synchronous while an AsyncStorage bridge handles all async I/O. This pattern resolves the async-sync impedance mismatch without requiring async language features or a blocking runtime.

  1. Create — An AsyncStorage session initializes with in-memory buffers for KV, Blob, and Object primitives, each tracking which keys are dirtied.
  2. Hydrate — The bridge populates buffers from the real backend via async reads, confined entirely outside the sync core.
  3. Execute — The sync core runs against in-memory buffers. Every write dirties the key; every read hits the buffer. CAS compare-and-swap operates entirely in memory.
  4. Drain and flush — The bridge collects dirty mutations and flushes them to the real backend via async writes. Only mutated keys traverse the async boundary.

Key properties:

  • 0 core changes — Storage interfaces remain pure-sync. AsyncStorage buffers implement the same interfaces without modification.
  • Dirty-tracking as bridge — The drain phase produces only the delta, minimizing bandwidth and write cost.
  • Atomic flush is caller-controlled — The session exposes the dirty delta; the bridge layer decides flush strategy: atomic within a single CAS namespace, or best-effort across independent stores.
  • Thread-safe by design — Buffers use shared ownership with interior mutability, safe for sequential job queues in native builds while remaining usable in WASM.
Figure 1: AsyncStorage bridge: sync core operates on in-memory buffers; async I/O confined to hydrate and flush phases.

CAS Coordination

All cross-instance Intent claims flow through a single atomic gate: the Object Storage compare-and-swap.

  1. Read current state for an Intent key
  2. If the state permits the claim, issue an atomic compare-and-swap: “if still expected, replace with new”
  3. If the swap succeeds, the claim is won. If it fails, another instance claimed this Intent first.

This is the only coordination primitive in nex. The CAS backend must provide:

  • Linearized execution — CAS contention serializes without additional locking.
  • Strong consistency — Every read sees the latest committed state. No eventual consistency window.
  • Atomic write gating — When an instance flushes its dirty Object delta, the backend applies all CAS operations atomically. If any CAS fails, the instance learns which keys failed and can roll back locally.

Suitable backends include SQLite (WAL mode), etcd, and blockchain ledgers.

Tiered Storage Model

The storage orchestration layer binds three temperature tiers into a unified persistence model. A flush cursor advances as Facts are committed.

Tier Temperature Backend Examples Contents
Hot In-memory, strongly consistent Object CAS namespace Recent Facts, active Intents, coordination state
Warm Frequently read, eventually consistent KV storage Published Facts, configuration Hints
Cold Archived, content-addressed Blob storage Fact streams, C2PA provenance bundles, resolved Intent logs

Data graduates through tiers: hot mutations flush to warm storage; warm data ages into cold archival. Snapshots at each tier enable recovery and replay from any point in the flush history.

nex as Execution over Shared Memory

Any storage backend that implements the three primitives turns an independent codebase into a nex instance. The AsyncStorage bridge is the universal pattern: an existing implementation conforms to the KV, Blob, and Object interfaces, the bridge wraps it with in-memory buffers and dirty tracking, and the sync core runs against the buffers without knowing which backend sits behind them.

Storage does one thing: store. It persists the FIH graph and scales without bound. On top of this, the nex core reads the graph as memory and acts on it — interpreting behavior specifications, issuing new Facts and Intents, and contributing evolved patterns back. The agent concept dissolves into this simpler model: storage as shared memory, nex as the execution loop that reads from it and writes back to it. Every backend — filesystem, database, graph memory, another nex — is indistinguishable from the core’s perspective; what a nex becomes depends on what the stored specifications describe, not on which backend sits behind them.

Relationship to SSCCS and ExaVerif

Component Role
SSCCS Foundational model (Segment / Scheme / Field / Observation)
ExaVerif (ev CLI) Reference verification engine; backend for nex-ev
neXus Platform (spec + runtime + blackboard + governance)
nex Autonomous agent binary executing .nex contracts

nex-ev is the first production-grade nex instance, proving the model.

Ecosystem Implications

  • Language agnostic: developers write nex instances in their preferred language.
  • Reuse of existing code: a large Python simulation, a legacy C++ solver, or a Node.js API server can become a nex agent with minimal glue code.
  • No central control: agents run independently, communicate via the blackboard, and compose into larger workflows without modifying the core runtime.

Example conceptual Python binding:

import nex

class MyAgent(nex.Agent):
    def on_intent(self, intent):
        result = self.run_simulation(intent.params)
        self.post_fact("simulation_result", result)

nex.run(MyAgent())

Getting Started

# Install the neXus runtime (placeholder)
cargo install nexus-runtime

# Run a nex instance (example: nex-ev)
nexe run --instance ev --contract verify_xif.nex

# Query the blackboard
nexe blackboard get --hash <fact-hash>

Future Directions

  • Cross‑domain merging – nex-bio Facts feeding into nex-rtl (e.g., neuro‑inspired hardware design).
  • Federated blackboards – Multiple neXus clusters exchanging Facts via secure, signed channels.

Conclusion

The nex platform is a synthesis fabric. The core provides the immutable, verifiable substrate; every language and domain attaches to it like plugins.