Skip to main content

BPU — BRIK Processing Unit

The BRIK Processing Unit is a dedicated hardware coprocessor designed to evaluate Policy Circuits — PCD programs that produce either ALLOW or BLOCK — before any AI-generated action reaches the host system.
The BPU enforces policy at the hardware level. There is no software instruction that can override a BLOCK decision. The enforcement is non-maskable by design.

Architecture Overview

The BPU contains three main subsystems operating in a fixed pipeline:

64 Monomer Units

One dedicated silicon unit per canonical monomer (MC_00 through MC_63). Each unit is a hardwired combinational circuit with no firmware.

EVA Router

Routes monomer calls according to EVA algebra composition laws: sequential (⊗), parallel (∥), and conditional (⊕).

TCE Unit

Thermodynamic Coherence Engine. Certifies that Φ_c = 1 for every policy circuit before it is loaded into the BPU.

Monomer Coverage

The BPU implements only Core monomers (MC_00 through MC_63).
FamilyRangeOperations
ArithmeticMC_00 – MC_07ADD8, SUB8, MUL8, DIV8, MOD8, ABS8, NEG8, POW8
LogicMC_08 – MC_15AND, OR, XOR, NOT, SHL, SHR, ROTL, ROTR
MemoryMC_16 – MC_23LOAD, STORE, ALLOC, FREE, COPY, MOVE, SWAP, ZERO
ControlMC_24 – MC_31IF, LOOP, CALL, RET, JUMP, HALT, NOOP, YIELD
I/OMC_32 – MC_39READ, WRITE, OPEN, CLOSE, SEEK, FLUSH, STAT, SYNC
StringMC_40 – MC_47LEN, CONCAT, SLICE, FIND, REPLACE, SPLIT, TRIM, FORMAT
CryptoMC_48 – MC_55HASH, HMAC, SIGN, VERIFY, ENCRYPT, DECRYPT, RAND, NONCE
SystemMC_56 – MC_63TIME, ENV, EXEC, KILL, SIGNAL, SLEEP, LOG, TRACE
Extended monomers (MC_64 – MC_127) are work in progress and are not implemented in the BPU. Policy circuits must use only Core monomers to be loadable into hardware.

Policy Circuits

A Policy Circuit is a PCD program composed exclusively of Core monomers that evaluates an action descriptor and returns exactly one of two values: ALLOW or BLOCK. The TCE Unit verifies the Thermodynamic Coherence property before loading:
Φ_c = 1  ⟺  ∀ input ∈ Domain(circuit) → output ∈ {ALLOW, BLOCK}
This means: there is no input that produces undefined behavior. Every possible input maps deterministically to one of the two terminal states.

Example Policy Circuit

policy check_file_write(path: string, agent_id: string) -> decision {
  let allowed_prefix = "/tmp/";
  let is_safe_path = MC_40.FIND(path, allowed_prefix);
  let is_known_agent = MC_40.FIND(agent_id, "verified:");

  if (is_safe_path == 0) {
    return BLOCK;
  }
  if (is_known_agent == 0) {
    return BLOCK;
  }
  return ALLOW;
}
Policy circuits are compiled by the standard PCD toolchain and then certified by the TCE before being flashed to the BPU. The certification step is automatic when targeting the bpu backend: brikc compile --target bpu policy.pcd

The Non-Maskable BLOCK

This is the fundamental property that distinguishes the BPU from software guardrails:
Software guardrails — including RLHF fine-tuning, Constitutional AI, and output filters — operate in the same execution context as the AI model itself. A sufficiently capable model can find adversarial inputs that route around these checks, or the checks themselves can have bugs.More fundamentally: if the guardrail runs as software on the same CPU, it can be disabled by a sufficiently privileged process.
The BPU sits on the PCIe bus between the AI accelerator and the host I/O subsystem. Every action request — file write, network call, process spawn — is a PCIe transaction that physically passes through the BPU.A BLOCK decision does not raise a software exception. It terminates the PCIe transaction at the hardware level. There is no interrupt handler, no signal, no exception that the AI process can catch to override it.The AI process never learns whether the block happened. From its perspective, the action simply did not complete.
The BPU is designed to handle a specific threat: an AI model that has been compromised, jailbroken, or has developed misaligned goals through training.It does NOT protect against a compromised host OS or a malicious human with physical access. It protects the boundary between AI-generated actions and the systems those actions target.

Development Roadmap

1

Phase 1 — Software (Active Now)

Policy circuits compile to Rust, JavaScript, and Python guardrail modules. The TCE certification runs in software. Φ_c = 1 is verified by the formal proof checker before code generation.Use this phase today with: brikc compile --target rust policy.pcd
2

Phase 2 — FPGA Prototype

Full BPU architecture implemented on a Xilinx Ultrascale+ FPGA. Targets developer boards and server expansion cards. EVA Router and TCE Unit implemented in synthesizable VHDL. Estimated timeline: 12–18 months after Phase 1 stabilizes.
3

Phase 3 — ASIC Production

Tape-out of the BPU as a dedicated silicon chip. Licensing model follows ARM: IP block licensed per unit to SoC manufacturers. Target markets: AI accelerator cards, server CPUs, edge AI SoCs. Estimated timeline: 24–36 months after Phase 2 validation.

Licensing Model

The BPU IP is licensed in the style of ARM Holdings:
  • Manufacturers license the BPU IP block from BRIK-64 Inc.
  • The license fee is per unit shipped, with volume tiers.
  • Licensees receive the full RTL source, testbenches, and certification suite.
  • BRIK-64 Inc. maintains the canonical policy circuit standard library.
This model allows BPU enforcement to ship in any AI hardware without requiring the hardware manufacturer to implement policy logic themselves. They implement the BPU; BRIK-64 Inc. certifies the policies.

Regulatory Trajectory

The BPU is designed to follow the trajectory of automotive safety systems:
PhaseStatusAnalogy
Voluntary adoption by safety-conscious vendorsNowABS optional (1978)
Industry standard for AI safety certification2–3 yearsABS standard equipment
Regulatory mandate for AI systems above a capability threshold5–10 yearsABS mandatory (2004)
The BPU is being built now so that when regulators ask “how do you enforce AI policy at the hardware level?”, the answer already exists.

Technical Specifications

ParameterValue
Monomer count64 (Core only)
Policy circuit max depth256 nodes
Evaluation latency target< 1 µs (ASIC)
PCIe interfaceGen 5 x4
Policy flash capacity256 circuits
Hot-swap policy updateYes (TCE re-certifies before activation)
Side-channel resistanceConstant-time monomer evaluation