ABS Core v4.5.0

Octagon Architecture - Design Principles

Octagon Architecture - Design Principles

Philosophy: Conceptual separation for clarity, pragmatic integration for delivery.
Current Status: Modular Monorepo (v4.3.3 Institutional-Ready) Focus: Forensic-Grade AI Governance & Sovereign Security.

What is the Octagon?

The Octagon Strategy is an architectural design pattern that separates AI governance into 8 conceptual pillars.

Each pillar has a single, well-defined responsibility and clear boundaries with other pillars.

Think: Unix philosophy for AI governance. Each component does one thing well.

Forensic Integrity Layer (Security Hardening)

As of v1.0.0, ABS Core implements a strict Forensic Integrity Layer to protect against local escalation and IPC tampering:

  1. Worker Thread Isolation (GAP-07): The WASM policy engine is isolated from the main process via dedicated Node.js Worker Threads. This prevents memory corruption or side-channel attacks on the main Hub.
  2. Authenticated IPC (GAP-15): All communication between the Hub and Workers is signed using HMAC-SHA256.
    • Per-worker shared secrets generated at bootstrap.
    • Monotonic nonces for replay protection.
    • 5-second TTL on all messages.
  3. HSM Security Proxy (GAP-16): Cryptographic operations are proxied through a hardened interface that prevents direct access to the HSM session, enforcing an immutable audit trail for every signature.

The Eight Pillars

          OID
       (Identity)
           │
     ┌─────┼─────┬─────┐
     │           │     │
    OCS         AICCP  ARCHAEO
 (Economic)  (Change) (Forensics)
     │           │     │
     └───┬───────┴─────┤
         │             │
      ABS CORE      LEDGER
      (Runtime)    (Audit)
         │             │
     ┌───┴───────┬─────┘
     │           │
    CHI        CORTEX
 (Cognitive)  (Memory)

1. OID - Sovereign Identity

Responsibility: Who is the agent?
Functions:

  • DID (Decentralized Identifier) generation
  • Ed25519 key pair management
  • Signature verification
  • Identity attestation

Current Status (v4.3.3):

  • [OK] Implemented in /modules/identity/
  • Integration: Used by ABS Core for request signing
  • Anti-Hermes: Includes OID Model Allowlist to strictly enforce approved LLMs per identity.

2. OCS - Economic/Cloud Sentinel

Responsibility: Can the agent afford this action?
Functions:

  • Token quota management
  • Cloud cost estimation
  • Budget enforcement
  • Rate limiting

Current Status (v4.3.3):

  • [OK] Implemented in /modules/security/ (basic token limits)
  • Roadmap: Full FinOps integration (Q3 2026)

3. AICCP - AI Change Control Protocol

Responsibility: Is this change approved?
Functions:

  • Approval workflows (M-of-N signatures)
  • Change request tracking
  • Irreversible operation gating
  • Human-in-the-loop enforcement

Current Status (v4.3.3):

  • [OK] Implemented in /modules/quorum/ (basic approval)
  • Roadmap: Full ITIL-style change management (Q3 2026)

4. ARCHAEO - Technical Forensics

Responsibility: Why did this happen? (Forensic Analysis) Functions:

  • Automated evidence collection
  • Anomaly detection in decision chains
  • Technical affidavit generation
  • Root cause analysis (AI-driven)

Current Status (v4.3.3):

  • [OK] Implemented in /modules/archaeo/
  • Production-ready as the 8th pillar.

5. ABS Core - Central Runtime

Responsibility: Execute governance decisions.
Functions:

  • Policy evaluation (WASM engine)
  • Request interception
  • Orchestration between pillars
  • Fail-closed enforcement

Current Status (v4.3.3):

  • [OK] Fully Implemented in /core/ and /modules/quorum/
  • Production-ready
  • Anti-Hermes: Includes Cron Re-eval for time-delayed policy re-evaluation of scheduled actions.

6. CHI - Cognitive Hallucination Interface

Responsibility: Is the agent confused or manipulated?
Functions:

  • Prompt injection detection
  • Semantic drift analysis
  • PII leakage prevention
  • Jailbreak attempt recognition

Current Status (v4.3.3):

  • [OK] Partially Implemented in /modules/shield/
  • Anti-Hermes: SKILL_AUDIT actively blocks ungoverned agent-generated code execution (exec, spawn, eval).
  • Roadmap: PII and Deep Semantic Drift (Q2 2026)

7. CORTEX - Memory & Reputation

Responsibility: What has the agent done before?
Functions:

  • Long-term agent memory (vector DB)
  • Behavioral pattern analysis
  • Reputation scoring
  • Anomaly detection

Current Status (v4.3.3):

  • [OK] Partially Implemented in /modules/shield/
  • Anti-Hermes: CORTEX Integrity handles hash-chained mutation tracking and drift detection against memory poisoning.
  • Roadmap: VectorDB LLM-based behavioral analysis (Q3 2026)

8. LEDGER - Immutable Audit

Responsibility: Prove what happened and why.
Functions:

  • Cryptographic audit trail (SHA-256 chain)
  • Tamper-proof decision log
  • Compliance evidence generation
  • Forensic replay

Current Status (v4.3.3):

  • [OK] Implemented in /modules/audit/
  • PostgreSQL + hash chain
  • Production-proven

Implementation Status

Current (v4.5.0) - Multi-Repo Workspace

Repository Structure (corrected — the tree below is what actually exists on disk, not a single monorepo):

PROJETO/
├── abs-core/          # ABS Core (Pillar 5) — engine WASM, SDK, mcp-gateway, telemetry
│   └── modules/       # adversarial-analysis, auth-worker, bridge, firewall,
│                      # gateway, quorum, shield, telemetry, telemetry-svc, vault
├── OID/               # Sovereign Identity (Pillar 1) — own git repo
├── OCS/               # Economic/Cloud Sentinel (Pillar 2) — own git repo
├── AICCP/             # AI Change Control Protocol (Pillar 3) — own git repo
├── ARCHAEO/           # Technical Forensics (Pillar 4) — own git repo
├── CHI/               # Cognitive Hallucination Interface (Pillar 6) — own git repo
├── CORTEX/            # Memory & Reputation (Pillar 7) — own git repo
└── LEDGER/            # Immutable Audit (Pillar 8) — own git repo

Why multiple repos instead of one monorepo?

  1. Each pillar (OID, LEDGER, QUORUM, CORTEX, ARCHAEO, CHI, OCS, AICCP) ships and versions independently.
  2. abs-core itself stays a pnpm workspace monorepo for its own internal packages.
  3. Cross-pillar calls go over IPC-HMAC-signed HTTP, not direct imports — see Authentication.

Conceptual boundaries enforced:

  • [OK] Clear module interfaces (TypeScript exports)
  • [OK] Dependency rules (modules can't import from each other directly)
  • [OK] Separate configuration
  • [OK] Independent testing

Design Principles

1. Single Responsibility

Each pillar does one thing and does it well.

Example:

  • OID: Manages identity (period)
  • LEDGER: Stores decisions (period)
  • ARCHAEO: Analyzes why (period)

Anti-pattern:

  • ✕ OID also doing audit logging
  • ✕ LEDGER also doing policy evaluation
  • ✕ ABS Core absorbing all functionality

2. Clear Boundaries

Pillars communicate via well-defined interfaces.

Example:

// ABS Core asks OID for identity
const identity = await oid.verify(signature, publicKey);

// ABS Core tells LEDGER to record decision
await ledger.append({ decision, timestamp, identity });

// ABS Core asks ARCHAEO for forensic check
const analysis = await archaeo.analyze(decisionId);

Benefits:

  • Easy to test (mock interfaces)
  • Easy to replace (swap implementations)
  • Easy to scale (deploy independently)

3. Fail-Closed Enforcement

If any pillar fails, default to DENY.

Example:

  • OID service down? → Reject request (can't verify identity)
  • LEDGER service down? → Reject request (can't audit)
  • CHI service down? → Configurable (shadow mode vs hard block)

Why: Security > availability in governance systems.

4. Horizontal Scalability

Each pillar can scale independently.

FAQ

"Is Octagon just marketing?"
No. It's a design constraint that keeps architecture clean. But yes, it's also a memorable framework for explaining the system.

"Why 8 pillars specifically?"
Emergent design. We identified 8 distinct governance concerns. The 8th, ARCHAEO, solidified the model as an Octagon.

"Can I use ABS Core without the other pillars?"
Yes. ABS Core (Pillar 5) works standalone. Other pillars are optional enhancements.

Honest Assessment

What Octagon IS:

  • [OK] Architectural design pattern
  • [OK] Conceptual separation of concerns
  • [OK] Roadmap for future scaling
  • [OK] Helps explain complex system

What Octagon is NOT:

  • ✕ 8 uniformly-mature services — OID, LEDGER, ARCHAEO, OCS, AICCP, CORTEX, and CHI are separate repositories today (see the corrected repository structure above), but CHI and CORTEX are partial implementations — see CHI and Cortex Memory.
  • ✕ Fully implemented across the board (CHI, CORTEX pending)
  • ✕ Marketing fluff (real technical constraint)

Transparency Commitment

Current state (v4.5.0):

  • 6/8 pillars fully implemented; CHI and CORTEX are partial (see their feature pages for exact scope).
  • Architecture: Multi-repo workspace, not a single monorepo (pragmatic choice)

Promise:
We will never claim microservices exist until they actually ship. Current documentation makes the monorepo reality clear.

Questions:

System Architecture

Understanding the ABS Core Runtime Enforcement Layer and Agent IAM infrastructure.

ABS Core Engine Internals

Implementation evidence and mechanics of the Rust-based governance kernel.

On this page

Octagon Architecture - Design PrinciplesWhat is the Octagon?Forensic Integrity Layer (Security Hardening)The Eight Pillars1. OID - Sovereign Identity2. OCS - Economic/Cloud Sentinel3. AICCP - AI Change Control Protocol4. ARCHAEO - Technical Forensics5. ABS Core - Central Runtime6. CHI - Cognitive Hallucination Interface7. CORTEX - Memory & Reputation8. LEDGER - Immutable AuditImplementation StatusCurrent (v4.5.0) - Multi-Repo WorkspaceDesign Principles1. Single Responsibility2. Clear Boundaries3. Fail-Closed Enforcement4. Horizontal ScalabilityFAQHonest AssessmentTransparency Commitment