Octagon Architecture - Design Principles

Philosophy: Conceptual separation for clarity, pragmatic integration for delivery.
Current Status: Modular Monorepo (v4.3.2 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:

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.
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.
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.2):

[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.2):

[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.2):

[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.2):

[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.2):

[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.2):

[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.2):

[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.2):

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

Implementation Status

Current (v1.0.0) - Modular Monorepo

Repository Structure:

/abs-core  (single monorepo)
  ├── /core           # ABS Core (Pillar 5)
  ├── /modules
  │   ├── /identity   # OID (Pillar 1) [OK]
  │   ├── /security   # OCS (Pillar 2) [OK]
  │   ├── /quorum     # AICCP (Pillar 3) [OK]
  │   ├── /archaeo    # ARCHAEO (Pillar 4) [OK]
  │   ├── /audit      # LEDGER (Pillar 8) [OK]
  │   └── ...         # Supporting modules
  └── /adapters       # External integrations

Why monorepo?

Faster iteration: Single codebase, easier refactoring
Simpler deployment: One Docker image, one binary
Easier debugging: No cross-repo dependency hell
Startup pragmatism: Don't prematurely optimize

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 separate repositories (yet)
✕ 8 microservices (yet)
✕ Fully implemented (CHI, CORTEX pending)
✕ Marketing fluff (real technical constraint)

Transparency Commitment

Current state (v1.0.0):

8/8 pillars implemented (CHI and CORTEX partially implemented via Anti-Hermes vaccine subset).
Architecture: Modular monorepo (pragmatic choice)

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

Questions:

Architecture: [email protected]
Roadmap: [email protected]
Source code: https://github.com/abs-core/abs-core

Octagon Architecture - Design Principles

On this page