System Architecture

Two services, two Kubernetes nodes, no cloud dependency for inference. Every component is designed for observability, auditability, and graceful degradation.

NEXI — Product LayerPort 8000 · i9 Inference NodeINTENT INTERPRETERRule pre-filter + LLM fallbackCONTEXT LOADERMemory manifest assemblyOPTION GENERATORLiteLLM → vLLM → fallbackPOLICY FILTERParallel dry-run evaluationEVALUATOR4-dimension weighted scoringSELECTORRank + confidence checkPLAN COMPILERDAG validation + compilationDISPATCHERExecution runner dispatchXNCH — Control PlanePort 8001 · i7 Memory NodeAUTHJWT + public-key cryptoSESSIONInit + rate-limit + dedupMEMORY — 4 LAYERSSensory · Working · Episodic (pgvector) · Pattern / GraphPOLICY ENGINEYAML rules · versionedGOVERNANCEActors · weights · auditVERDICTJWT signing · decision ledgerEXECUTIONOutcome callback · deltaAUTONOMOUS LEARNINGPattern extraction · score adaptation · policy candidates (6h loop)verdict requestpolicy checkcontext readINFRASTRUCTURERedis · PostgreSQL + pgvector · Kuzu Graph · SQLite · agentmemory · Langfuse

Data Flow

01

1. Session Initiation

A request arrives at Nexi (port 8000). Nexi calls XNCH to validate the auth token, resolve the actor, and create a session context with rate-limit enforcement and KV-cache dedup.

02

2. Context Assembly

Nexi queries XNCH memory for relevant episodes, learned patterns, and policy references. The 4-layer memory system retrieves sensory signals, working memory, episodic history, and graph relationships.

03

3. Option Generation & Filtering

Nexi generates candidate actions via LiteLLM (with fallback chain). Each option is sent to XNCH for parallel dry-run policy evaluation. BLOCKed options are dropped; MODIFY verdicts alter the action spec.

04

4. Scoring & Selection

Surviving options receive a weighted composite score — policy alignment, expected outcome, risk, and context fit. The highest-scoring option is selected unless confidence is too low (triggers escalation).

05

5. Authoritative Verdict

The selected action is submitted to XNCH for binding re-evaluation. If allowed, XNCH issues a signed JWT execution token. BLOCK verdicts are written to the immutable decision ledger.

06

6. Execution & Outcome

The signed payload is dispatched to the execution runner. On completion, the outcome is sent back through XNCH, which computes a prediction delta and triggers the next learning cycle if needed.

Design Principles

Graceful Degradation

Every component has a fallback. If vLLM is down, LiteLLM routes to a secondary model, then llama.cpp, then rule-based templates. No single point of failure stops the system.

Observability by Default

Every LLM call, policy evaluation, and verdict is traced via Langfuse. System events are written to a JSONL audit file. The decision ledger is append-only and immutable.

State Versioning

Every state change increments a version counter. XNCH and Nexi verify state version alignment before proceeding. Stale state is detected and rejected.

Deployment

Two physical nodes, Kubernetes, no cloud dependency for inference. Full deployment in under 30 commands.

Memory Node (i7)

kubectl label node i7-node role=memory

XNCH Server (port 8001)
PostgreSQL + pgvector
Redis (sensory + working memory)
Kuzu graph database
agentmemory

Inference Node (i9)

kubectl label node i9-node role=inference

Nexi Server (port 8000)
vLLM with NVIDIA GPU ≥20Gi VRAM
LiteLLM proxy (port 4000)
llama.cpp (CPU fallback)
Langfuse observability