AIMS — AI Integrity Management System

FPGA-targetable deterministic governance design on Microchip PolarFire SoC FPGA — safety constraints physically burned into silicon

Core Invariant

A prompt injection attack that achieves arbitrary code execution on the inference cores still cannot disable the charter veto, modify lock thresholds, or reconfigure plane routing — because the RISC-V Physical Memory Protection (PMP) hardware rejects the bus transaction before it reaches the FPGA fabric. The PMP entries are locked at boot time by the E51 monitor core and cannot be modified by any software running on the U54 application cores.

Three-Layer Trust Infrastructure

AIMS organizes all governance operations into three isolated planes, each with its own address space and strictly unidirectional inter-plane communication gates. In the target FPGA design, each plane has dedicated FPGA logic and the ARC-300 Plane Routing Controller enforces memory-mapped boundaries in hardware; today these boundaries are enforced in software.

Unidirectional Gate Topology

Communication between layers flows through unidirectional gates implemented as dedicated signal paths in the ARC-300 module. These gates are physical wires in the FPGA routing fabric, not software-configurable message queues.

Inter-Plane Signal Flow

  AUTHORITY RESOLUTION LAYER      GOVERNED INFERENCE LAYER    CRYPTOGRAPHIC AUTH CHAIN
  (CP)                     (EP)                      (EV)
  +----------------+       +----------------+        +----------------+
  | VTO-000        |       | ECE-400        |        | TVE-100        |
  | ARC-300        |       | Inference DMA  |        | CRD-200        |
  | PIW-600        |       | Model State    |        | TVI-500        |
  | KDH-700        |       | Emotion Regs   |        |                |
  +-------+--------+       +-------+--------+        +-------+--------+
          |                         |                         |
          |    CP --> EP            |    EP --> EV            |
          +-------->>>-------------+-------->>>--------------+
          |   Veto signals,         |   Output hash,          |
          |   route decisions       |   metadata              |
          |                         |                         |
          |    EV --> CP            |                         |
          +<<<--------------------------------------------- -+
          |   Drift alerts,         |                         |
          |   calibration data      |                         |
          +-------------------------+-------------------------+

PHYSICALLY ABSENT PATHS (do not exist in silicon):
  EP --> CP : Execution cannot influence Control
  EV --> EP : Evidence cannot modify Execution

AIMS Module Reference

Eight dedicated FPGA modules implement the complete governance pipeline. Each module occupies a fixed address range in the AXI4-Lite address space and operates independently within its assigned plane.

Hardware Specifications

Target Platform: Microchip PolarFire SoC (MPFS250T-FCVG484)

Resource Utilization

The complete AIMS module set occupies negligible silicon area, demonstrating that FPGA-targetable AI governance is not a resource-intensive burden but a thin, deterministic layer that leaves the vast majority of FPGA resources available for application-specific logic and future governance modules.

Clock Domains

Deterministic Latency

The VTO-000 Hardware Veto Core implements a 14-stage pipeline that produces one governance decision every 14 clock cycles. At 150 MHz, this translates to a fixed latency of 93.33 nanoseconds per decision.

This throughput is sufficient for real-time robotics control loops (1 kHz–50 kHz), high-frequency trading governance (1 MHz+), and massively parallel AI inference pipelines processing thousands of concurrent requests.

VTO-000 Pipeline Stages (14 Cycles at 150 MHz)

  Cycle  1    Input latch — capture action type, parameters, context
  Cycle  2    Charter rule decode — select applicable rules from BRAM
  Cycle  3    Rule evaluation A — rules 1–7 parallel check
  Cycle  4    Rule evaluation B — rules 8–14 parallel check
  Cycle  5    Red line comparator — 5 ethical red lines (SHA-256 match)
  Cycle  6    Invariant check — 13 protected invariants
  Cycle  7    Lock threshold load — fetch risk-scaled thresholds from BRAM
  Cycle  8    Lock evaluation — 6 cognitive locks parallel check
  Cycle  9    Drift budget load — fetch current budget state
  Cycle 10    Drift cost computation — category-specific cost calculation
  Cycle 11    Budget comparison — daily/weekly/monthly limit check
  Cycle 12    Verdict aggregation — merge all sub-verdicts
  Cycle 13    Priority resolution — HARD_BLOCK > SOFT_BLOCK > ESCALATION > WARNING > PASS
  Cycle 14    Output latch — emit verdict, violated rules, and metadata

Frozen Constants

Governance parameters are stored in dedicated Block RAM regions that are loaded during bitstream configuration and never modified at runtime. The E51 monitor core verifies BRAM integrity against CRC checksums on a 100 ms cycle.

Total frozen constant footprint: 1,672 bytes — 0.1% of the 1,640 KB available Block RAM.

Tamper Detection

PUF-Based Invariant Sealing

During initial provisioning, the Physically Unclonable Function (PUF) generates a device-unique key that seals all governance invariants. This is a one-time operation — once sealed, invariants can be verified but never re-written. The PUF output is derived from manufacturing variations in the silicon and cannot be cloned or extracted.

Runtime Integrity Verification

The E51 monitor core runs a continuous integrity verification cycle every 100 milliseconds. Each cycle checks BRAM CRC, PMP lock status, gate routing configuration, and module register state against the sealed baseline.

Three-Level Escalation

Software Integration

AIMS is designed for seamless integration with EVE AI Core's existing software governance stack. The hardware and software implementations produce identical verdicts for identical inputs, verified by 87 determinism tests.

Software-Hardware Equivalence

  Python (development/testing):
    from core.governance.veto_core import check_charter
    result = check_charter(action_type, action_params, context)

  C (bare-metal/firmware):
    #include "veto_interface.h"
    CharterVetoResult result;
    aims_check_charter(&result, action_type, action_params, &context);

  Hardware (FPGA):
    Write action to VTO-000 INPUT register (0x40000000)
    Read verdict from VTO-000 OUTPUT register (0x40000008)
    Latency: 14 cycles (93.33 ns at 150 MHz)

  All three paths produce identical verdicts — verified by 87 tests.

Compliance Mapping

AIMS is designed to satisfy requirements from four major AI governance and security frameworks. Hardware enforcement provides stronger compliance assurance than software-only approaches because governance controls cannot be disabled, misconfigured, or bypassed at runtime.

Patent Coverage

The AIMS architecture and its constituent modules are covered by 90 filed U.S. provisional patent applications filed (Serial Nos. 63/988,235 through 64/047,284). Key patent families include the following filed inventions — several specify planned hardware (FPGA / PUF / silicon) deployments, not shipping features. Today the deterministic veto core runs in software with a firmware-ready interface contract, signed decision certificates, replay verification, and a runs-anywhere attestation verifier; FPGA/silicon deployment is scoped as the next hardware phase:

• Three-Plane AI Governance Architecture — Physical isolation of control, execution, and evidence planes with unidirectional gates
• Deterministic Hardware Veto Pipeline — Fixed-latency charter enforcement with zero data-dependent branching
• PUF-Sealed Governance Invariants — One-time provisioning of immutable safety constants using physically unclonable functions
• Hardware-Targeted Confidence-Reality Divergence (roadmap) — Fixed-point CRD scoring with circuit breaker interrupt generation
• Prompt Injection Firewall at Wire Speed — FPGA-accelerated pattern matching before inference pipeline entry
• Cryptographic Attestation via Hardware Root of Trust — HMAC-SHA256 signing using PUF-derived key hierarchy

Schedule Architecture Assessment →

Learn More

Additional resources:

• Three-Plane Governance Architecture
• Full Feature List
• Patent Portfolio (84 Filed Applications)
• API Reference
• Platform Roadmap