ABS Core

Architecture Deep Dive

How the WASM Kernel, CHI Engine, AICCP Gate, OCS Sentinel, and L2 Ledger operate as a single integrated runtime

Architecture: Sovereign Governance Runtime

ABS Core is not a proxy. It is a Governance Kernel — a single runtime that sits between your agent and the external world, enforcing behavioral, economic, and cryptographic accountability on every action.

The 9 Sovereign Pillars (CHI, QUORUM, MCP Bridge, Ledger, AICCP, OCS, CORTEX, Policy DSL, IaC Guard) are co-deployed as a single runtime. None operates in isolation. This document describes how they compose.


The Governed Transaction Flow

sequenceDiagram
    participant A as Agent
    participant P as Governance Kernel (Edge / On-Prem)
    participant CHI as CHI Engine
    participant K as Policy Engine (WASM)
    participant OCS as OCS Sentinel
    participant L as Polygon L2 Ledger
    participant EXT as External System

    A->>P: Tool call / Write operation
    P->>CHI: Validate intent declaration
    CHI-->>P: Drift score + PII check + hallucination check
    P->>OCS: Pre-flight: cost + regulatory check
    OCS-->>P: PASS or BLOCK (offline — no network)
    P->>K: Policy evaluation (WASM, <5ms)
    K-->>P: ALLOW / DENY / HOLD / SLASH

    alt ALLOW
        P->>EXT: Forward signed request
        EXT-->>P: Response
        P->>L: Hash + anchor decision proof
        P-->>A: Response + receipt
    else DENY
        P->>L: Hash + anchor block record
        P-->>A: 403 + policy violation detail
    else HOLD
        P->>L: Hash + anchor pending record
        P-->>A: 202 Accepted — awaiting quorum
    else SLASH
        P->>L: Hash + anchor breach record
        P->>P: Trigger kill switch + slash bond
        P-->>A: Connection reset
    end

Layer 1: CHI — Cognitive Host Interface

The first thing the kernel does is demand that the agent explain itself. The CHIAnalysis envelope — intent, risk self-assessment, next action — must arrive with the request or be extractable from the request context.

The CHI engine then runs three checks:

  • Semantic drift: Computes distance between declared intent and session goal. Blocks if distance exceeds threshold.
  • PII and leakage vaccines: Scans the intent declaration and payload for credentials, PII, system prompt fragments, high-entropy obfuscated content.
  • Hallucination check: Validates that entities referenced in next_action (file paths, endpoints, agent IDs) actually exist in the known environment.

If CHI blocks, the policy engine is never reached. The block is recorded with the drift score, the exact vaccine that triggered, and the full CHIAnalysis envelope — all of which become part of the immutable proof record.


Layer 2: OCS — Offline Pre-flight

Before reaching the policy engine, the request passes through the Offline Cost Sentinel. OCS runs entirely in-process — no network required.

OCS enforces two categories of pre-flight rules:

Economic: Does this action exceed the agent's token budget, API spend limit, or infrastructure cost ceiling? If yes, block before any external call is made.

Regulatory: Does this action violate LGPD, PCI-DSS, HIPAA, or internal data residency policies? For example: an agent attempting to send a payload containing a CPF number to an endpoint outside the Brazilian perimeter is blocked by OCS before the network call is ever initiated.

OCS is not about saving money. It is about preventing regulatory violations before they happen — not logging them after.


Layer 3: Policy Engine — WASM Kernel

The Rust binary compiled to WebAssembly. Runs synchronously. Deterministic — the same input always produces the same verdict.

Input: Structured decision envelope containing:

  • Agent ID and bonding status
  • Action type and payload hash
  • CHI analysis summary
  • OCS pre-flight result
  • Shannon entropy score of the payload
  • Semantic intent classification (small LLM, local)

Policy format: Versioned YAML contracts. Each agent has a policy contract identified by its hash. The hash of the policy version active at decision time is included in the audit record — making policy changes auditable.

Outputs:

  • ALLOW — forward, sign receipt, anchor proof
  • DENY — block, return 403 with rule ID, anchor proof
  • HOLD — queue for human quorum (M-of-N approval), anchor pending proof
  • SLASH — for bonded agents only: deduct from bond, trigger kill switch, anchor breach proof

Layer 4: AICCP — Mandatory Change Gate

AICCP (Autonomous Instruction Compliance Control Protocol) activates before any irreversible write operation: database mutations, infrastructure apply, financial transactions, email sends.

It forces the agent through a structured decision cycle:

  1. The agent must produce an ADR (Architecture Decision Record) — a human-readable justification of why this change is necessary
  2. The ADR is evaluated against the change policy (who can approve what, under what conditions)
  3. If approved: the change proceeds and the ADR is chained into the WORKLOG
  4. If denied or ambiguous: escalates to human quorum

AICCP's contribution to the audit record is critical in regulated sectors: when a regulator asks "why did the agent modify this record", the answer is a structured ADR with a cryptographic chain of custody — not a log timestamp.


The Forensic Ledger

Every verdict — regardless of outcome — is recorded in the immutable ledger. The record contains:

  • Full CHIAnalysis envelope (what the agent claimed it was doing)
  • OCS pre-flight result (what economic/regulatory checks ran)
  • Policy version hash (what rules were active)
  • Verdict with matched rule ID
  • Kernel signature
  • SHA-256 hash of the previous record (Merkle chain)
  • Timestamp

This chain is designed to be anchored on Polygon L2 via the AuditEmitter contract. The local hash chain is active and cryptographically sound from day one. On-chain anchoring to Polygon is available in the Enterprise tier under Early Access — contact the team to enable it for your tenant.

The forensic ledger API (/v1/audit/verify) allows independent verification of chain integrity without requiring on-chain confirmation.


Deployment Architecture

graph TD
    subgraph Customer Perimeter
        AGENT[AI Agent] --> PROXY[Magic Proxy / Sentinel SDK]
        PROXY --> KERNEL[Governance Kernel — WASM]
        KERNEL --> OCS_LOCAL[OCS — Offline Sentinel]
    end

    subgraph ABS Edge — Cloudflare Workers
        EDGE_PROXY[Edge Proxy — 300+ locations]
        EDGE_CHI[CHI Engine]
        EDGE_POLICY[Policy Engine — WASM]
    end

    subgraph Ledger
        POLYGON[Polygon L2 — Public Verifiable]
    end

    subgraph TEE — Optional
        ENCLAVE[AWS Nitro Enclave — Policy Execution]
    end

    PROXY --> EDGE_PROXY
    EDGE_PROXY --> EDGE_CHI --> EDGE_POLICY
    EDGE_POLICY --> POLYGON
    EDGE_POLICY -.->|Enterprise| ENCLAVE

For on-premise deployments (banking, regulated healthcare, government), the governance kernel runs entirely inside the customer's perimeter. ABS Core never receives payload data. Only anonymized metadata and proof hashes leave the perimeter.

For TEE deployments (AWS Nitro Enclaves), the policy execution environment is hardware-attested. Even the infrastructure operator cannot observe or modify policy logic at runtime.


Technical Stack

  • Kernel: Pure Rust, no-std compatible, WASM target — deterministic, auditable binary
  • Ledger: SHA-256 Merkle chain in Cloudflare Durable Objects + optional Polygon L2 anchoring (Enterprise)
  • Database: Agent registry, RBAC, policy contracts in Cloudflare D1
  • Compute: Cloudflare Workers (edge) + self-hosted Docker (on-prem)
  • TEE: AWS Nitro Enclaves for maximum sovereignty

Latency Budget

ComponentAdded latency (warm)
CHI evaluation3–6ms
OCS pre-flight1–2ms (offline)
Policy Engine (WASM)5–8ms
AICCP gate2–4ms (write ops only)
L2 anchoringasync — does not block response
Total (read ops)~12–18ms
Total (write ops)~18–25ms

L2 anchoring is asynchronous. The response to the agent is returned immediately after the policy verdict. The Polygon transaction is submitted in parallel and confirmed within the next block.

On this page