Skip to main content

​
BPU — BRIK Processing Unit

​
From CPU to GPU to BPU: The Missing Processor

Computing has evolved through two major processor paradigms:
ProcessorYearPurposeKey Innovation
CPU1971General computationSequential instruction execution
GPU1999Parallel accelerationThousands of cores for data parallelism
BPU2026Regulatory verification64 hardwired monomer units + EVA Router + CMF Unit
The CPU computes. The GPU accelerates. But neither verifies. When an AI model generates an action — write a file, send a network request, spawn a process — no hardware component evaluates whether that action should be allowed. The BRIK Processing Unit fills this gap. It 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 (⊕).

CMF Unit

Coherence Metric Framework unit. 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_47CONCAT, SPLIT, SUBSTR, LEN, UPPER, LOWER, TRIM, MATCH
CryptoMC_48 – MC_55HASH, VERIFY_HASH, SIGN, ENCRYPT, DECRYPT, RAND, DERIVE, SEAL
SystemMC_56 – MC_63TIME, PID, WRITE_FD, DEC2, SEND, RECV, LOG, ASSERT
Extended monomers (MC_64 – MC_127) are implemented in software. In the BPU, Core monomers run in silicon; Extended monomers run on the host CPU. 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 CMF Unit verifies the closure 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 CMF before being flashed to the BPU. The certification step is automatic when targeting the bpu backend: brikc compile --target bpu policy.pcd

​
Real-World Applications

​
Autonomous Warehouse Robots

A warehouse robot controlled by AI must never leave its designated zone, exceed safe speeds near humans, or access restricted areas: 
policy warehouse_movement(zone_id: i64, speed: i64, area_type: i64) -> decision {
  // Zone boundary check
  if (zone_id < 1) { return BLOCK; }
  if (zone_id > 50) { return BLOCK; }

  // Speed limit near humans (area_type 2 = human zone)
  if (area_type == 2) {
    if (speed > 3) { return BLOCK; }
  }

  // Restricted areas (area_type 9 = restricted)
  if (area_type == 9) { return BLOCK; }

  return ALLOW;
}
With a BPU, even a compromised AI controller cannot command the robot into a restricted zone — the hardware intercepts and blocks the action before it reaches the motor controller.

​
Delivery Drones with Geofencing

A delivery drone must respect altitude limits, no-fly zones, and return-to-base conditions — regardless of what the AI navigation system decides: 
policy drone_flight(altitude: i64, lat_zone: i64, battery_pct: i64) -> decision {
  // Hard altitude ceiling (FAA limit)
  if (altitude > 400) { return BLOCK; }

  // No-fly zones (zone codes 100-199)
  if (lat_zone > 99) {
    if (lat_zone < 200) { return BLOCK; }
  }

  // Force return when battery critical
  if (battery_pct < 15) { return BLOCK; }

  return ALLOW;
}

​
Surgical Robotic Arms

Medical robots operating near patients require force limits and movement boundaries that cannot be overridden by any software — including a malfunctioning AI: 
policy surgical_movement(force_n: i64, distance_mm: i64, zone: i64) -> decision {
  // Maximum force (Newtons * 10 for integer precision)
  if (force_n > 50) { return BLOCK; }

  // Movement boundary
  if (distance_mm > 200) { return BLOCK; }

  // Critical zone requires reduced force
  if (zone == 1) {
    if (force_n > 20) { return BLOCK; }
  }

  return ALLOW;
}

​
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.
RLHF teaches an AI to want to do right. The BPU prevents it from doing wrong. Education fails. Physics does not.

​
Development Roadmap

1

Phase 1 — Software (Active Now)

Policy circuits compile to Rust, JavaScript, and Python guardrail modules. The CMF 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 CMF 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.

​
Regulatory Trajectory

The BPU follows 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 (CMF re-certifies before activation)
Side-channel resistanceConstant-time monomer evaluation

CMF — Coherence Metrics

The formal property Φ_c = 1 and how it is verified.

EVA Algebra

The composition laws that give Policy Circuits their formal guarantees.