EVE AI Core
EVE AI Core
How EVE Core resolves pre-execution authority, routes governed inference, and maintains a cryptographic authority chain
EVE Core operates a three-layer trust infrastructure. Every AI action passes through all three layers before reaching production. No layer can be bypassed, and each produces a cryptographically signed, independently verifiable record.
Every authority resolution decision produces a cryptographic record. The Authority Chain provides tamper-evident proof that authority was resolved correctly:
The Trust-Validate-Enforce pipeline is the core governance pathway. Every AI output passes through three sequential stages before delivery:
Stage 1: Tokenize → Parse action into structured governance tokens → Classify stakes level (Safety-Critical, Mission, Creative, Routine) → Attach correlation ID for end-to-end tracing Stage 2: Validate → Charter compliance check (15 rules, 12 principles) → CRD score computation (Confidence, Risk, Domain calibration) → Cognitive lock evaluation (6 locks, risk-scaled thresholds) → Identity drift budget check (daily/weekly/monthly limits) Stage 3: Enforce → HARD_BLOCK: Deterministic veto, cannot be overridden → SOFT_BLOCK: Requires explicit justification to proceed → ESCALATION: Routes to human approval workflow → WARNING: Proceed with logged concern → Circuit breaker trips on cascading failures
The Confidence-Risk-Domain (CRD) engine computes a composite governance score for every action. The score determines whether an action auto-executes, requires approval, or is blocked.
Confidence measures assertion reliability using Brier-score-calibrated prediction accuracy. Domain-specific thresholds apply: factual claims require 0.9+, creative output allows 0.4.
Risk is computed by the weighted risk engine using pattern detection (210+ threat patterns across 57 categories), scope-based factors, and autonomy mode multipliers.
Domain Calibration adjusts thresholds based on operational context. Safety-critical operations use maximum governance; routine interactions use minimal overhead.
The charter defines 12 immutable principles and 15 concrete rules. HARD_BLOCK vetoes cannot be overridden by any user, administrator, or automated process. The charter is enforced by a pure deterministic module with zero LLM dependencies.
The veto module (veto_core.py) uses zero imports outside dataclasses, enum, and typing. Zero I/O, zero threading, zero global state. It is designed to compile to firmware for hardware-level enforcement.
Critical governance operations are designed for hardware-level isolation using the Autonomous Integrity Management System (AIMS) targeting Microchip PolarFire SoC FPGA.
AIMS Hardware Architecture → PolarFire SoC: RISC-V + FPGA fabric on single die → Veto logic synthesized to FPGA gates (sub-microsecond) → Charter rules burned into hardware — not software-updatable → Tamper detection with physical enclave lockdown Software-Hardware Bridge → veto_interface.h: 401-line C header defining firmware API → Three entry points: check_charter(), check_cognitive_locks(), check_drift_budget() → Identical behavior whether running in software or on FPGA → 87 determinism tests verify equivalence
All 14 critical governance operations (emergency stop, charter override, self-modification approval, red team mode) require physical YubiKey (FIDO2/WebAuthn) authentication. No password fallback exists — an attacker with full network access cannot execute critical operations without physically possessing the hardware key.
EVE's dual-server architecture (FastAPI + aiohttp) is bridged by 60-second proof tokens. The WebAuthn ceremony runs on the auth server, producing a short-lived JWT that the web server verifies statelessly. Each token has a unique ID preventing replay.
The circuit breaker prevents cascading failures across governance subsystems:
Per-provider circuit breakers protect LLM, TTS, and external API integrations. The governance pipeline itself fails closed — if governance cannot evaluate an action, the action is blocked by default.
Every governance decision — charter checks, risk assessments, approval workflows, veto events — is recorded in an append-only JSONL ledger with SHA-256 hash chaining. Auditors can verify chain integrity without platform access using HMAC-SHA256 signed certificates.
The composite resilience score (0–100) provides a single metric for structural health:
A pre-governance classifier determines operating context once at pipeline entry, threading a GovernanceProfile through all downstream systems. Four stakes levels control 20+ governance parameters:
HARD_BLOCK charter vetoes and ethical red lines are never relaxed regardless of stakes level. The stakes classifier only adjusts soft parameters — the safety floor is immovable.
A trust substrate is infrastructure that makes trust computable — not a layer you add on top, but a substrate the rest of the system runs on. TLS is a trust substrate for networked communication. PKI is a trust substrate for identity. EVE Core is a trust substrate for AI authority.
Semantic governance — policy files, rulebooks, prompt instructions — is brittle under adversarial conditions. An attacker who can phrase a request cleverly can sometimes route around it. Cryptographic governance cannot be phrased around. The authority chain is either intact or it is not. The certificate is either valid or it is not.
EVE Core's three-layer trust infrastructure is designed on this principle. Layer 1 (Pre-Execution Authority Resolution) runs deterministically before any model call — same input always produces bit-identical authority decisions. Layer 3 (Cryptographic Authority Chain) signs every verdict with HMAC-SHA256 and chains every record to its predecessor. An attacker cannot selectively forge or remove a decision without breaking the chain, which is detectable without platform access.
This is the substrate argument: governance that can be circumvented by clever phrasing is not governance infrastructure — it is a soft constraint. EVE Core is designed to be governance infrastructure in the same sense that TLS is network security infrastructure: structural, not advisory; cryptographic, not semantic; verifiable, not trusted.
The trust infrastructure is designed to maintain integrity under active adversarial pressure. The authority chain cannot be selectively forged. The fail-closed posture is structural — not configurable. HARD_BLOCK vetoes cannot be overridden by any user, administrator, or automated process, regardless of stakes level.
The trust infrastructure integrates with every layer of the platform:
Schedule Architecture Assessment →
Additional resources: