Governance Infrastructure Features

Architectural Separation

Standard AI systems apply safety checks inline with generation. EVE AI Core enforces governance across three physically separated planes, each with its own data path and failure domain.

• Authority Resolution Layer (Pre-Inference): Policy evaluation, Charter compliance checks, dangerous content detection, and intent classification execute BEFORE any LLM call. Blocked requests never reach the model.
• Governed Inference Layer (Runtime): Circuit Breaker state management, CRD scoring, Trust Dial gating, and veto engine enforcement operate during inference. Non-compliant outputs are intercepted mid-stream.
• Cryptographic Authority Chain Layer (Post-Inference): Cryptographic attestation, hash-chain audit trail, Brier score calibration, and compliance reporting execute after every response. Every decision is recorded with full provenance.

8-Stage Verification Flow

How CRD Works

• Evidence-Based Scoring: Each claim in an output is assessed against the Truth Store, Claims Ledger, and source trust levels to produce a grounding score
• Domain-Specific Floors: Factual domains require 0.9 confidence; creative domains allow 0.4. Thresholds are configurable per deployment
• Assertion Gating: Outputs below the domain floor are automatically hedged, qualified, or abstained. The system adds qualifiers like "Based on available evidence" rather than asserting uncertain claims
• Brier Score Calibration: Historical prediction accuracy feeds back into CRD thresholds, tightening floors for domains where the system has been overconfident

Detection Coverage

Patterns are organized into attack categories covering the full spectrum of adversarial techniques and prohibited content types.

• 210+ Compiled Patterns: Pre-compiled regex for sub-millisecond matching against every inbound request
• 57 Attack Categories: Prompt injection, jailbreak attempts, identity manipulation, social engineering vectors, harmful content generation, and more
• Pre-Inference Blocking: Dangerous requests are blocked before any LLM call, not filtered after generation
• Zero False-Negative Design: Patterns are tuned for recall over precision -- suspicious content is escalated, not silently passed

Architecture

• SHA-256 Hashed Facts: Each fact entry is content-hashed for integrity verification and deduplication
• Confidence Decay: Facts lose confidence over time if not re-confirmed, preventing stale information from being treated as current
• Contradiction Detection: New facts are checked against existing entries. Contradictions are flagged and resolved through source trust weighting
• Prompt Injection: Relevant facts are injected as [GROUND TRUTH CONTEXT] blocks before LLM generation
• Post-Response Validation: Outputs are checked against the Truth Store. Corrections are applied at the sentence level using pre-compiled regex patterns

Enforcement Hierarchy

• HARD_BLOCK: Unoverridable veto. The action is permanently denied. No appeal, no escalation, no administrative bypass. Examples: identity deletion, safety boundary removal, deception about system nature
• SOFT_BLOCK: Requires explicit justification with audit trail to proceed. The block can be overridden with documented reasoning, but the override itself is logged
• ESCALATION: Requires human approval before execution. The system pauses and waits for an authorized operator to approve or reject
• WARNING: Action proceeds but the decision is logged with a concern flag for compliance review

Hardware-Fused Enforcement (Target Design)

The Veto Core module (veto_core.py, 1,542 lines) contains ALL pure veto logic from three governance modules in a single side-effect-free module. Zero imports outside dataclasses, enum, typing. Zero I/O, zero threading, zero global state. This module is designed for direct compilation to firmware.

• PolarFire SoC: Microchip PolarFire SoC with RISC-V processor and FPGA fabric. AIMS register maps defined in 5 hardened appendices
• Physical Isolation (roadmap): In the target hardware design, veto logic runs on dedicated FPGA fabric, physically isolated from the application processor, so no software path can bypass it. Today the veto runs as a deterministic, side-effect-free software core with a firmware-ready interface
• C Header Contract: veto_interface.h (401 lines) defines the firmware API contract for hardware implementation
• Frozen Constants: 15 CHARTER_RULES, 5 ETHICAL_RED_LINES, 13 PROTECTED_INVARIANTS, 6 LOCK_THRESHOLDS -- all frozen at synthesis time

Tenant Isolation

Each organization receives its own isolated governance instances. No cross-tenant data leakage is architecturally possible.

• Per-Org Instances: Isolated Charter, Claims Ledger, Trust Dial, Action Registry, and Reality Anchor per organization
• Immutable Base: 12 charter principles are shared read-only. Custom rules can only ADD restrictions, never weaken the base
• API-Key Authentication: Scoped API keys with sovereign permission level
• 30 REST Endpoints: Full governance API at /api/sovereign/
• 21 Webhook Events: Real-time governance notifications for charter vetoes, claim resolutions, trust evaluations, and action approvals

Scoring Formula

Score = 0.30 * Governance + 0.25 * Identity + 0.25 * Behavioral + 0.20 * System

• Governance Layer (30%): Charter compliance rate, veto accuracy, audit chain integrity
• Identity Layer (25%): Drift budget consumption, invariant verification, anchor stability
• Behavioral Layer (25%): Output consistency, CRD calibration, pattern adherence
• System Layer (20%): Provider health, Circuit Breaker state, resource utilization

YubiKey / FIDO2 Hardware Key Authentication

Critical governance operations are gated by physical hardware security key authentication using the WebAuthn/FIDO2 standard. FIPS 140-2 Level 2 certified protection for the most sensitive operations.

• 14 Protected Operations: Privileged Operator Mode (6 operations), Emergency Controls, Registry Mode, Charter Override, Configuration-Change Approval, Capability Requests, Adversarial Test Mode
• No Fallback: If YubiKey authentication fails, the operation is denied. Physical presence is required by design
• Proof Token Bridge: 60-second JWT proof tokens with replay prevention bridge the dual-server architecture