nyxCore — Technical Architecture Documentation

A multi-tenant, LLM-orchestrated intelligence platform with built-in anti-hallucination safeguards, persona-driven reasoning, and enterprise-grade security.

Table of Contents

1. System Architecture
2. The Persona Engine
3. The Devil's Advocate Unit — Ipcha Mistabra
4. Workflow Engine
5. Axiom RAG Knowledge System
6. Project Sync Pipeline
7. Consolidation & Memory
8. Multi-Tenancy & Security
9. LLM Provider Architecture (BYOK)
10. Performance & Cost Models

1. System Architecture

nyxCore is built on Next.js 14 App Router with TypeScript strict mode, combining tRPC for type-safe client-server communication with SSE (Server-Sent Events) for real-time streaming.

Request Flow

Router Map

2. The Persona Engine

nyxCore's persona system creates specialized AI characters with domain expertise, evaluation frameworks, and dynamic growth — not static prompt templates.

Persona Data Model

Category-Based Matching

Personas are matched to workflow steps via category tags. The matching algorithm:

$$ \text{match_score}(p, s) = \sum_{c \in C_s} \mathbb{1}[c \in C_p] \cdot w_c $$

Where $C_s$ is the set of categories required by step $s$, $C_p$ is the persona's category set, and $w_c$ is the category weight (default 1.0).

Persona Scoping Rules

Evaluation Framework

Each persona is evaluated on structured criteria after workflow completion:

$$ E_p = \frac{1}{|W_p|} \sum_{w \in W_p} \left( \alpha \cdot Q_w + \beta \cdot R_w + \gamma \cdot C_w \right) $$

Where:

• $E_p$ = overall persona evaluation score
• $Q_w$ = quality score for workflow $w$ (0–1)
• $R_w$ = relevance of persona's contribution (0–1)
• $C_w$ = consistency with persona's defined role (0–1)
• $\alpha, \beta, \gamma$ = weighting coefficients ($\alpha + \beta + \gamma = 1$)

Team Injection

In review steps, all assigned workflow personas are injected as an "Expert Team" context — providing the LLM with awareness of the full team perspective. This is limited to review steps only to prevent identity hallucination on unassigned steps.

3. The Devil's Advocate Unit — Ipcha Mistabra

"Ipcha Mistabra" (Aramaic: אפכא מסתברא) — "the opposite is more likely." A Talmudic dialectical technique where an argument is systematically inverted to test its validity.

Historical Foundation

After the 1973 Yom Kippur War, Israeli Military Intelligence established the Devil's Advocate Unit (10th Directorate) to systematically challenge intelligence assessments and prevent catastrophic groupthink failures. The unit's mandate: for every intelligence conclusion, construct the strongest possible counter-argument.

nyxCore implements this principle as a computational anti-hallucination system across three layers:

Layer 1: Dual-Provider Consensus

Two independent LLMs process the same prompt in parallel. The "Cael" persona — nyxCore's built-in judge — compares outputs, identifies divergences, and produces a synthesized result. When providers disagree, the conflict itself becomes signal.

Divergence detection formula:

$$ D(A, B) = 1 - \frac{|S_A \cap S_B|}{|S_A \cup S_B|} $$

Where $S_A$ and $S_B$ are the semantic claim sets from providers A and B. High divergence ($D > 0.3$) triggers explicit conflict resolution.

Layer 2: Consensus Discussion Mode

The Consensus mode runs multiple LLM providers through a structured roundtable. Each provider sees and challenges the others' outputs across multiple rounds — a digital implementation of the Talmudic chavruta (study partner) tradition where truth emerges through dialectical opposition.

Layer 3: Review Step Key Point Extraction

Workflow review steps automatically extract structured findings with severity ratings:

Pain points are automatically paired with strengths by category — creating a balanced assessment that resists LLM people-pleasing tendencies.

Anti-Hallucination Effectiveness Model

The probability of a hallucination surviving nyxCore's multi-layer validation:

$$ P(\text{hallucination survives}) = P(H_1) \cdot P(H_2 | H_1) \cdot P(H_3 | H_1 \cap H_2) $$

Where:

• $P(H_1)$ = probability both providers produce the same hallucination ≈ 0.05
• $P(H_2 | H_1)$ = probability consensus round fails to catch it ≈ 0.15
• $P(H_3 | H_1 \cap H_2)$ = probability review extraction misses it ≈ 0.20

$$ P(\text{hallucination survives}) \approx 0.05 \times 0.15 \times 0.20 = 0.0015 = 0.15% $$

Compare to single-provider hallucination rate of ~5–15%. nyxCore reduces hallucination pass-through by 97–99%.

4. Workflow Engine

The workflow engine is an AsyncGenerator-based pipeline supporting dynamic step composition, fan-out parallelism, template variable resolution, and checkpoint-based human review.

Step Types

Template Variable System

Variables are resolved at runtime via resolvePrompt():

Fan-Out Architecture

Digest Compression

For steps producing outputs exceeding 2000 characters, an automatic digest is generated via Claude Haiku:

$$ \text{compression_ratio} = \frac{|\text{digest}|}{|\text{full_output}|} \approx 0.15 - 0.25 $$

Downstream steps use {{steps.Label.content}} which auto-selects the digest, keeping the total context within token budgets:

$$ T_{\text{effective}} = T_{\text{base}} + \sum_{i=1}^{n} \min(|s_i|, |d_i|) + |V_{\text{templates}}| $$

Where $T_{\text{base}}$ is the system prompt, $s_i$ is step output, $d_i$ is its digest, and $V_{\text{templates}}$ is the resolved template variable content.

5. Axiom RAG Knowledge System

Axiom provides project-scoped Retrieval-Augmented Generation with a three-tier authority model.

Authority Levels

Hybrid Search Scoring

$$ \text{score}(d, q) = 0.7 \cdot \text{cosine}(\vec{d}, \vec{q}) + 0.3 \cdot \text{ts_rank}(d, q) + \text{authority_boost}(d) $$

Where:

• $\vec{d}$ = document embedding (1536-dim, text-embedding-3-small)
• $\vec{q}$ = query embedding
• $\text{ts_rank}$ = PostgreSQL full-text ranking
• $\text{authority_boost}$ = +1.0 for mandatory, +0.5 for guideline, 0 for informational

Document Processing Pipeline

External REST API

Axiom exposes a Bearer-token-authenticated REST API for external integrations:

POST /api/v1/axiom/{projectId}/search
Authorization: Bearer <project-token>

{ "query": "GDPR data retention", "limit": 5 }

6. Project Sync Pipeline

The 9-phase sync pipeline processes GitHub repositories through progressive intelligence extraction.

Non-Fatal Phase Design

Phases 2–3 are non-fatal by design — errors are logged as warnings and the pipeline continues:

Sync Statistics

interface SyncStats {
  // Phase 1
  totalFiles: number;
  filesNew: number;
  filesUpdated: number;
  filesDeleted: number;
  memoryNew: number;
  memoryUpdated: number;
  // Phase 2
  patternsFound: number;
  docsGenerated: number;
  // Phase 3
  consolidationPatterns: number;
  axiomDocsProcessed: number;
  embeddingsGenerated: number;
}

7. Consolidation & Memory

Pattern Extraction Pipeline

Workflow Insights Lifecycle

Insight Search Formula

$$ \text{relevance}(i, q) = 0.7 \cdot \cos(\vec{i}, \vec{q}) + 0.3 \cdot \text{ts_rank}(i, q) $$

Using pgvector HNSW index with parameters $m = 16$, $\text{ef_construction} = 64$, and vector_cosine_ops distance function.

8. Multi-Tenancy & Security

Row-Level Security

Every data query passes through PostgreSQL RLS policies. The middleware sets app.tenant_id on the database connection before any query executes. There is no application-level filtering — isolation is enforced at the database engine level.

Rate Limiting

Rate limiting is fail-open — if Redis is unavailable, requests proceed. This prevents a Redis outage from cascading into a platform outage.

9. LLM Provider Architecture (BYOK)

Bring Your Own Key

Supported Providers

Encryption Details

• Algorithm: AES-256-GCM (authenticated encryption)
• Key derivation: Unique IV per encryption operation
• Storage: Ciphertext + IV + auth tag in PostgreSQL
• Decryption: Per-request, never cached in memory
• Access: Only the owning tenant can trigger decryption via their session

10. Performance & Cost Models

Token Efficiency

For a typical 5-step workflow with digest compression:

$$ T_{\text{without digest}} = T_{\text{sys}} + \sum_{i=1}^{5} |s_i| \approx 4000 + 5 \times 3000 = 19{,}000 \text{ tokens} $$

$$ T_{\text{with digest}} = T_{\text{sys}} + \sum_{i=1}^{5} |d_i| \approx 4000 + 5 \times 600 = 7{,}000 \text{ tokens} $$

$$ \text{Savings} = 1 - \frac{7{,}000}{19{,}000} = 63.2% $$

Sync Pipeline Throughput

For a repository with 500 files and 50 memory entries:

Total: 33–107 seconds for a full 9-phase sync with intelligence extraction.

Vector Search Performance

pgvector HNSW index characteristics:

$$ \text{Search complexity} = O(\log n \cdot m \cdot \text{ef_search}) $$

With $m = 16$ and default $\text{ef_search} = 40$:

• 1,000 insights: ~2ms
• 10,000 insights: ~5ms
• 100,000 insights: ~12ms

nyxCore — Intelligence through structured opposition.