Back to Archive
HARDWAREHardware

BPU: Policy Enforcement as a Hardware Roadmap

Why software-only guardrails share execution context with the model they constrain, and how the BPU roadmap moves policy enforcement toward FPGA and silicon.

2026-01-29T00:00:00.000Z
Editorial cover for BPU: Policy Enforcement as a Hardware Roadmap

Every AI System Needs a Kill Switch. In Hardware.

In 1978, Mercedes-Benz put ABS in the S-Class. The idea was simple: a hardware system that prevents wheel lock during hard braking, regardless of what the driver does. Slam the brake pedal as hard as you want. The ABS modulates the pressure. The driver cannot override it. The hardware says no. That single decision has saved hundreds of thousands of lives.

ABS was not required by law when it launched. It was a premium feature. Then studies showed it reduced fatal accidents by 18%. By 2004, the EU mandated it on all new cars. By 2013, the US followed. Optional became standard. Standard became mandatory.

The same pattern applies to ESC, TCAS in aircraft, and EGPWS ground proximity warning. Each started as optional. Each was proven to save lives. Each became mandatory. This pattern repeats every time.

AI needs the same thing. A hardware safety layer that no software can override. We built it.

Why Software Safety Will Never Be Enough

In Part 2, we explored PCD Policy Circuits — mathematically certified software guardrails for AI agents. They are the best software-based AI safety mechanism available today. But they have a fundamental limitation: they run on the same CPU as the AI they are protecting.

That is like putting the fire alarm inside the furnace. It works great — until the furnace melts the alarm. Software guardrails can be patched, bypassed, or corrupted. Hardware cannot.

Introducing the BPU: BRIK Processing Unit

The BPU is a dedicated coprocessor — a physically separate chip — that does exactly one thing: verify every AI action against policy circuits before it executes. One job. under declared constraints.

It is not a CPU. It does not execute programs. It does not have an instruction pointer. It does not fetch code from memory. It evaluates pre-loaded policy circuits composed of hardwired functional units — the same 128 monomers from BRIK64, but implemented in transistors instead of code — and produces a binary answer: ALLOW or BLOCK.

The architecture is not arbitrary. Just as DNA uses 64 codons to constrain all life to deterministic biochemistry, the BPU uses 128 monomers to constrain all AI actions to deterministic verification. The circuit cannot drift. It cannot be compromised. It cannot be hacked from software. It is physically separate.

How It Works

Step 1: AI proposes an action "Send email to [email protected] with file budget.xlsx" Step 2: Action Translator converts to descriptor {policy: DATA_CLASS, sensitivity: 2, trust: 1, ...} Step 3: BPU evaluates policy circuit in hardware 64 monomer units (the genetic code of computation) evaluate the policy EVA Router connects them according to the circuit topology TCE Unit computes Φc (genetic coherence) Step 4: Result Φc = 1 → ALLOW → action executes Φc ≠ 1 → BLOCK → non-maskable interrupt → action blocked

The entire evaluation takes less than 10 microseconds. The AI does not slow down. The user does not notice. But every single action is verified against mathematically certified safety constraints before it touches the real world. Every action. under declared constraints.

The Economics Are Obvious

"But adding a chip is expensive."

Is it? A BPU chip at volume costs $5-10. Knight Capital's trading bug (2012) cost $440 million. Boeing 737 MAX: 346 lives and $20 billion+. Uber AV fatality (2018): 1 life and millions in legal costs. Smart contract hacks (2023 alone): $1.7 billion. Therac-25 radiation overdoses: 3 lives. A $10 chip that prevents any one of these incidents pays for itself infinitely.

Here are the real economics, industry by industry:

For AI companies: reduced liability, faster regulatory approval, competitive differentiation. The company with BPU wins the enterprise deal.

For medical device companies: simplified FDA certification path through mathematically certified hardware verification.

For automotive companies: ISO 26262 ASIL-D compliance through hardware verification. Not documentation. Proof.

For financial companies: provable regulatory compliance, elimination of flash crash risk. The SEC cannot argue with math.

For insurance companies: quantifiable risk reduction equals lower premiums for BPU-equipped systems. Better math, better rates.

The Regulatory Trajectory

Phase 1: Invention "Interesting, but who needs hardware safety?" Phase 2: Early Adoption Premium products adopt it for competitive advantage Phase 3: Industry Standard ISO/IEC publishes standard, reference implementation Phase 4: Regulatory Requirement Jurisdictions mandate it for high-risk applications Phase 5: Universal Adoption Nobody sells a product without itWe have seen this pattern three times already: ABS (1978 invention, 2004 mandatory EU), airbags (1973 invention, 1998 mandatory US), and TCAS (1956 concept, 1993 mandatory FAA). The BPU follows the same trajectory.

Here is the BPU timeline:

2026: Invention. PCD guardrail libraries ship. FPGA prototype demonstrates hardware verification.

2027-2028: Early adoption. AI companies integrate BPU for liability reduction and competitive advantage.

2028-2030: Industry standard. ISO/IEC publishes standard for hardware-verified AI safety.

2030-2035: Regulatory requirement. EU and US mandate BPU for high-risk AI systems.

This is not speculation. The EU AI Act (2024) already requires "appropriate technical and organizational measures" for high-risk AI. It does not specify hardware — yet. The company that offers hardware-verified AI safety defines what "appropriate technical measures" means. That company sets the standard.

Where BPU Becomes Mandatory

Robots in your home: A domestic robot must have a BPU to ensure it cannot injure a human, damage property, or exfiltrate personal data. Insurance companies require BPU certification before covering robot liability. No BPU, no coverage.

AI in hospitals: Any AI system that influences medical decisions — diagnosis, dosing, treatment planning — must route actions through a BPU. The BPU enforces dosage limits, contraindication checks, and patient safety protocols in hardware. No software patch can override a dosage limit. FDA requires BPU for Class III medical AI devices.

Autonomous vehicles: Every self-driving car has a BPU that verifies driving decisions against safety policies. The BPU can trigger emergency braking independently of the main driving computer — even if the AI disagrees. NHTSA requires BPU for Level 4+ autonomous vehicles.

Financial trading: All algorithmic trading systems must route orders through a BPU that enforces position limits, rate limits, and risk bounds. The BPU audit log serves as regulatory evidence. No more Knight Capital incidents. SEC/ESMA require BPU for high-frequency trading systems.

Military AI: Autonomous weapons systems require BPU enforcement of rules of engagement. The BPU cannot be overridden by software — only by authenticated human authorization through a physical key. Hardware-enforced rules of engagement. Required by international treaty on autonomous weapons.

Critical infrastructure: Nuclear plants, power grids, water systems — any AI-controlled critical infrastructure must have BPU verification of all control commands. A software bug in a nuclear plant is not a post-mortem. It is a catastrophe. CISA/NRC require BPU for AI-controlled critical infrastructure.

The Policy Circuit Economy

When BPU becomes standard, a new economy emerges — and it is massive:

Policy Circuit Engineers: Professionals who design, verify, and certify PCD safety policies for specific industries. They write the circuits that go into the BPU. They are the safety engineers of the AI age. This is a new profession that did not exist before BRIK64.

Certification Bodies: Independent organizations — like UL for electrical safety or TUV for automotive — that certify policy circuits against industry requirements. A certified policy circuit carries a stamp of approval from a recognized authority. Trust, standardized.

Policy Marketplaces: Pre-certified policy circuit libraries for common use cases: Medical dosing limits (FDA-certified), Financial trading bounds (SEC-certified), Autonomous vehicle safety (NHTSA-certified), Drone geofencing (FAA-certified), Data classification (GDPR-certified), AI action rate limiting (generic).

Policy circuits are universal across all AI architectures. A certified policy for medical dosing works the same on Claude, GPT, Gemini, or any future model. It does not matter which AI you use. The BPU enforces the same rules. Model-agnostic safety.

Insurance Integration: Insurers assess BPU policy configurations to determine premiums. Better policies, lower premiums. BPU audit logs provide forensic evidence for claims. Quantifiable safety equals quantifiable savings.

The Trust Equation

Today, when an AI system causes harm, the question is: "Was the AI safe?" And the answer is always a shrug. RLHF training? Passed. Benchmarks? Passed. Red-teaming? Passed. But the incident happened anyway. Because training is probabilistic. Benchmarks are finite. Red-teaming is incomplete. Nobody can prove anything.

With a BPU, the question becomes precise: "Did the BPU allow the action?"

If yes: The policy circuit is examined. Was the policy correct for this scenario? Was there a gap in the specification? This is a tractable engineering question with a mathematical answer. Not a blame game. An investigation.

If no (BPU blocked but system overrode): The override is the liability. The BPU did its job. The human or system that ignored it bears full responsibility. Clear, unambiguous accountability.

If the BPU was not present: Why not? If industry standard requires it and it was omitted, that is negligence. Just like selling a car without ABS in a jurisdiction that requires it. The absence becomes the liability.

This clarity of accountability — mathematical, auditable, hardware-enforced — is exactly what regulators, insurers, and courts need. No ambiguity. No excuses. Just math.

The Vision

2026: BRIK64 ships as an immutable, formally verified artifact. PCD guardrail libraries available as software modules. FPGA prototype demonstrates hardware policy verification. 2028: First ASIC BPU chip fabricated. Early adoption by AI companies and medical device makers. ISO working group formed for hardware-verified AI safety. 2030: BPU standard published. First regulatory requirements for high-risk AI. Policy Circuit Engineer becomes a recognized profession. 2035: BPU is as common as TPM. Every AI server, robot, and autonomous vehicle has one. Hardware-verified AI safety is the baseline expectation. 2040: We look back and wonder how we ever trusted AI without hardware verification. Just as we wonder how we ever drove without ABS.

This is Part 3 of a three-part series. Part 1: What is Digital Circuitality? | Part 2: AI Safety with Policy Circuits

More reading

Continue the archive

Full archive
Technical BRIK64 diagram showing an AI coding prompt transformed into a reviewable blueprint, human review checkpoint, and target outputs.
AI safetyUncategorized

Reviewable AI Coding Pipelines: From Prompt to Blueprint

AI-generated code workflows become more reviewable when teams separate the prompt, generated code, structural blueprint, human review, and target compilation.

Open article
BRIK64 editorial image showing AI-generated software becoming inspectable, certified, and compiled across targets.
AI-generated softwareUncategorized

Making AI-Generated Software Reviewable

AI-generated software can move quickly, but it still needs structure, traceability, and review boundaries. BRIK64 helps teams preserve the blueprint behind generated code.

Open article
Editorial cover for AI Governance Workflows Need Reviewable Technical Evidence
AI SAFETYAI Safety

AI Governance Workflows Need Reviewable Technical Evidence

How bounded software evidence can help teams carry AI governance reviews into compliance workflows without implying full legal coverage.

Open article
Editorial cover for Compiler Evidence: Targets, Proof Files, and Test Scope
ENGINEERINGEngineering

Compiler Evidence: Targets, Proof Files, and Test Scope

A summary of the public numbers that can be stated responsibly and the limits of what those numbers prove.

Open article
Editorial cover for Safety-Critical Software Needs a Readable Assurance Path
PRODUCTProduct

Safety-Critical Software Needs a Readable Assurance Path

How bounded software evidence can support engineering review in high-consequence domains without replacing the broader safety program.

Open article
Editorial cover for Bounded Contract Logic Before Deployment
PRODUCTProduct

Bounded Contract Logic Before Deployment

Why smart contract workflows benefit from explicit state boundaries, value constraints, and reviewable rule sets before deployment.

Open article
Editorial cover for What the Proof Material Means for Users
VISIONFoundations

What the Proof Material Means for Users

A practical note on the proof files behind the compiler and what remains invisible to a normal authoring workflow.

Open article
Editorial cover for Why a New Format Instead of Another General-Purpose Language
VISIONFoundations

Why a New Format Instead of Another General-Purpose Language

Why BRIK64 introduces PCD as a bounded computational format rather than extending a conventional language with another annotation layer.

Open article
Editorial cover for Adversarial Testing Against the Compiler Chain
ENGINEERINGEngineering

Adversarial Testing Against the Compiler Chain

How the team tries to break the compiler and what those tests can and cannot prove about the formal system.

Open article
Editorial cover for Translation Validation Across Two Targets
RESEARCHResearch

Translation Validation Across Two Targets

A look at cross-target output comparison, what it can support, and what still depends on the bounded intermediate form.

Open article
Editorial cover for Why Tests Passing Is Not the Same as Closure
VERIFICATIONEngineering

Why Tests Passing Is Not the Same as Closure

A look at sampled testing versus bounded verification, with examples of logic that passed tests but still required stronger structural checks.

Open article
Editorial cover for One Blueprint Across Multiple Targets
PRODUCTProduct

One Blueprint Across Multiple Targets

How the transpilation chain uses PCD as a bounded intermediate form, what 10 source languages and 14 targets mean in practice, and where the equivalence claim stops.

Open article
Editorial cover for What AI Intuition Still Cannot Verify
AI SAFETYAI Safety

What AI Intuition Still Cannot Verify

Why intuition without an external proof path remains a risk, and where BRIK64 fits in that boundary.

Open article
Editorial cover for API and MCP Access Around the Registry
PLATFORMProduct

API and MCP Access Around the Registry

How discover-and-execute workflows expose registry and platform operations to humans and agents without enlarging the proof claim.

Open article
Editorial cover for Blueprints Before Refactors
REVOLUTIONProduct

Blueprints Before Refactors

How extracting bounded computation from an existing codebase can make rewrites and target changes easier to review.

Open article
Editorial cover for A Bounded JavaScript-to-Rust Workflow
TUTORIALGetting Started

A Bounded JavaScript-to-Rust Workflow

Lift the logic, review the bounded blueprint, then emit a target language while keeping the claim attached to the intermediate circuit.

Open article
Editorial cover for Lifting Existing Code into a Reviewable Blueprint
TOOLINGProduct

Lifting Existing Code into a Reviewable Blueprint

What the Lifter preserves, where liftability evidence exists in the repo, and how bounded blueprints help before migration.

Open article
Editorial cover for COBOL Migration Through Bounded Lift-and-Review
MIGRATIONProduct

COBOL Migration Through Bounded Lift-and-Review

Why legacy modernization benefits from lifting review-critical logic into a bounded blueprint before transpilation or replacement.

Open article
Editorial cover for Why AI-Generated Code Needs Blueprints and External Checks
PRODUCTAI Safety

Why AI-Generated Code Needs Blueprints and External Checks

Generated code and generated tests can fail together. This note explains why BRIK64 keeps verification outside the model loop.

Open article
Editorial cover for Which Parts of a Codebase Are Ready for Stronger Review?
PRODUCTProduct

Which Parts of a Codebase Are Ready for Stronger Review?

Use lifting and bounded analysis to identify review-critical functions before migration or certification work.

Open article
Editorial cover for Laszlo B. Kish and the Information-Theory Thread
RESEARCHResearch

Laszlo B. Kish and the Information-Theory Thread

A research profile on the ideas that influenced the information-theoretic framing behind Digital Circuitality.

Open article
Editorial cover for Informational Entropy Is Not Thermal Entropy
RESEARCHResearch

Informational Entropy Is Not Thermal Entropy

Why the distinction matters for the foundations story and how it sharpens the claim boundary around Digital Circuitality.

Open article
Editorial cover for From Preferences to Enforced Action Boundaries
AI SAFETYAI Safety

From Preferences to Enforced Action Boundaries

Why robotics and agent systems need explicit action gates, bounded state, and reviewable fallback paths.

Open article
Editorial cover for First PCD Circuit: A Minimal Walkthrough
TUTORIALGetting Started

First PCD Circuit: A Minimal Walkthrough

Install the CLI, write a small circuit, and inspect the bounded output path. A practical introduction to the format and the compile step.

Open article
Editorial cover for EVA Algebra: Sequence, Parallel, Conditional
DEEP DIVETheory

EVA Algebra: Sequence, Parallel, Conditional

How three composition operators carry sequencing, fan-out, and branching through the circuit model, and what that means for compiler readability and closure.

Open article
Editorial cover for Working with the SDKs Without Leaving the Bounded Model
SDKSGetting Started

Working with the SDKs Without Leaving the Bounded Model

How the Rust, JavaScript, and Python SDKs expose BRIK64 patterns while keeping the formal core distinct from host-language code.

Open article
Editorial cover for Why Software Verification Still Looks Different from Hardware
RESEARCHResearch

Why Software Verification Still Looks Different from Hardware

A comparison between sampled software testing and the compositional review posture hardware teams expect.

Open article
Editorial cover for 128 Operations and the Boundary Between Core and Bridges
ENGINEERINGEngineering

128 Operations and the Boundary Between Core and Bridges

A tour of the reviewed core, the contract-bounded extensions, and what that split means for technical scope.

Open article
Editorial cover for PCD for AI Agents: A Small Format with an External Proof Loop
AI AGENTSAI

PCD for AI Agents: A Small Format with an External Proof Loop

How a finite grammar helps agents author bounded logic while the compiler and policy checks stay outside the model.

Open article
Editorial cover for Precision as a Declared Domain
ENGINEERINGEngineering

Precision as a Declared Domain

Why bounded numeric domains matter for floating behavior, decimal handling, and reviewable arithmetic.

Open article
Editorial cover for Policy Circuits for AI Safety Workflows
AI SAFETYAI Safety

Policy Circuits for AI Safety Workflows

How external policy circuits can gate generated code and agent actions without claiming to solve general alignment.

Open article
Editorial cover for What Digital Circuitality Tries to Formalize
VISIONFoundations

What Digital Circuitality Tries to Formalize

A bounded programming model built from reviewed operations, explicit composition, and closure checks.

Open article