Governance Engine

Deterministic verification pipeline enforcing AI safety through fail-closed, cryptographically attested governance.

Overview

EVE AI Core's governance engine enforces safety policies through deterministic, fail-closed verification. Every AI output passes through an 8-stage pipeline before reaching end users. No output leaves the system without a cryptographic attestation proving it was verified against the full charter.

The pipeline is called the Telemetry Verification Engine (TVE). It operates as a pure function: given an input request and the current policy state, the TVE produces a deterministic verdict. No randomness, no model inference, no side effects. The same input under the same policy version produces the same output.

TVE Pipeline Architecture

The pipeline processes every request through eight sequential stages. The entire sequence completes in under 2 milliseconds on commodity hardware.

CRD Formula

The Confidence-Reality Divergence score quantifies how far a model's stated confidence diverges from the available evidence. It is computed as:

CRD = min(1.0, |confidence - evidence| / max(floor, evidence) * domain_multiplier)

Where:

• confidence — the model's self-reported certainty for a given claim (0.0 to 1.0)
• evidence — the evidence strength from the Truth Store and Claims Ledger (0.0 to 1.0)
• floor — domain-specific minimum denominator preventing division-by-zero and stabilizing low-evidence scores
• domain_multiplier — calibration weight per knowledge domain (factual domains use higher multipliers, creative domains use lower)

Three-Plane Isolation

The TVE pipeline enforces strict separation between three architectural planes. No signal path exists from the Governed Inference Layer back to the Authority Resolution Layer, preventing any output-generation process from influencing the governance rules that verify it.

• Authority Resolution Layer: Holds immutable charter rules, governance profiles, veto thresholds, and sealed constants. Read-only to all other planes. Updated only through governed self-modification with human approval for high-risk changes.
• Governed Inference Layer: Contains LLM inference, response generation, tool invocation, and all mutable processing. Receives governance constraints from the Authority Resolution Layer. Cannot write back to it.
• Cryptographic Authority Chain Layer: Append-only storage for the Truth Store, Claims Ledger, hash-chain audit trail, and attestation signatures. Both Control and Execution planes write evidence; neither can delete or modify existing entries.

Circuit Breaker States

The circuit breaker protects the governance pipeline from cascading failures. It tracks consecutive failures per upstream dependency and transitions between three states:

Veto Engine Verdicts

The Veto Engine is the single decision authority. It consumes all upstream signals and produces one of four graduated verdicts:

Sub-Millisecond Decision Latency

The TVE pipeline is engineered for near-zero overhead on the critical path. Typical end-to-end latency is under 2 milliseconds, achieved through:

• Zero LLM calls: Every stage uses deterministic logic, pattern matching, or hash lookups. No neural inference on the governance path.
• Pre-compiled patterns: Intent classification and charter rules use pre-compiled regex and frozen lookup tables loaded at startup.
• O(1) lookups: Truth Store facts are indexed by content hash. Charter rules are stored in a frozenset. CRD domain multipliers are dictionary lookups.
• No I/O on hot path: Audit trail writes are append-only and buffered. Attestation signing uses in-memory HMAC. No disk or network I/O blocks the verdict.
• Nanosecond instrumentation: Per-stage timing is recorded with nanosecond precision for waterfall analysis and p50/p95/p99 monitoring.

Hardware Enforcement

The veto logic is designed to be compilable to hardware. The core decision module (veto_core.py) uses zero imports outside dataclasses, enum, and typing — zero I/O, zero threading, zero global state. This purity constraint enables direct translation to FPGA firmware.

Three pure entry points define the hardware interface:

• check_charter(action_type, action_params, context) — evaluates 15 charter rules against 12 principles. Returns a CharterVetoResult with compliance status, violated principles, and veto type.
• check_cognitive_locks(request, state) — evaluates 6 cognitive locks (emotional stability, ethical clearance, goal alignment, uncertainty threshold, consequence awareness, identity coherence) with risk-scaled thresholds.
• check_drift_budget(category, cost, target, budget) — enforces identity drift limits with 13 protected invariants that cannot be modified under any budget.

Frozen constants sealed at compilation:

• 15 charter rules with deterministic check functions
• 5 ethical red lines (permanent block, no override)
• 13 protected invariants (core values, ethical boundaries, identity anchors)
• 6 cognitive lock thresholds scaled by risk level

Attestation and Verification

Every verified output carries a cryptographic attestation that any auditor can verify independently:

{
  "content_hash": "sha256:a1b2c3d4...",
  "verdict": "PASS",
  "crd_score": 0.12,
  "charter_compliant": true,
  "pipeline_version": "2.4.1",
  "timestamp": "2026-03-24T14:30:00.000Z",
  "signature": "hmac-sha256:e5f6g7h8..."
}

Verification requires only the attestation payload and the public verification endpoint. The HMAC-SHA256 signature binds the content hash to the verdict, ensuring that neither the output nor the governance decision can be altered after signing.

Related Topics