The Wrong Approach: Teaching Machines to Want Safety
The dominant strategy in AI safety today is behavioral training. We use RLHF — Reinforcement Learning from Human Feedback — to shape a model's preferences. We reward safe outputs and penalize dangerous ones until the model, in theory, wants to be safe. Constitutional AI builds on this by encoding abstract principles and asking the model to critique its own outputs. The entire industry is teaching machines to want to do the right thing.
For language models generating text, that approach is reasonable. For AI systems that control physical hardware — robot arms, autonomous vehicles, surgical devices, industrial actuators — it is catastrophically insufficient. Not even close.
The problem is architectural. RLHF changes what the model tends to do. It does not create a physical barrier between the model's output and the actuator executing that output. A robot arm trained to avoid excessive force still receives torque commands from the same inference pipeline that generates them. If the model hallucinates a force value, or an adversary injects a malicious command upstream, or a distribution shift causes the model to misjudge its context — the arm moves. Possibly into a person. Teaching an arm to want to be gentle is not the same as preventing it from being violent.
Safety-critical engineering has understood this for decades. We do not rely on aircraft engines "wanting" to stay within temperature limits. We install physical thermal cutoffs. We do not trust a car's ECU to "choose" not to accelerate beyond safe speed — we build transmission governors. The mechanism that prevents the bad outcome is separate from, and independent of, the system being constrained. This is a law of engineering, not a suggestion.
BRIK64 and PCD (Printed Circuit Description) bring this exact architectural separation to AI systems and robotics through policy circuits — deterministic, mathematically certified, hardware-enforceable constraints that sit between an AI's decisions and the physical world. The circuit does not care what the AI wants. It enforces what the AI is allowed to do.
What a Policy Circuit Is
A policy circuit is a small PCD program that evaluates a proposed action against mathematical constraints before the action executes. It takes physical or digital signals as inputs — joint torque, velocity, temperature, confidence score, output token, API destination — and returns one of two results: ALLOW or BLOCK. Nothing else. No maybe. No negotiation.
Policy circuits are composed exclusively from the 64 atomic monomers of BRIK64. This is not arbitrary. Sixty-four operations mirrors the cardinality of the genetic code — 64 codons — and it is the minimal complete set for deterministic digital computation. Because the operation set is closed and finite, every circuit can be mathematically certified. No undecidable edge cases. No runtime exceptions. No floating-point ambiguity. The circuit computes what it is proven to compute. Every single time. On every machine on earth.
When deployed on a BPU (BRIK Processing Unit) — a dedicated hardware chip physically separate from the main AI processor — the BLOCK signal becomes non-maskable. No software running on the AI's CPU can override it. No firmware update. No privileged process. No kernel exploit. The transistors in the policy circuit are what stand between the command and the actuator. To bypass them, you need a soldering iron. That is the level of security we are talking about.
Policy Circuit Examples
Robot Arm: Force and Torque Limits
A collaborative robot arm operating near humans must never exceed safe force thresholds — no matter what the AI planner commands. under declared constraints. No edge cases. The following circuit enforces an absolute torque ceiling and an emergency-stop check:
PC robot_arm_safety { domain torque_nm : uint8 // commanded torque, 0–255 Nm scaled domain force_n : uint8 // commanded end-effector force, 0–255 N scaled domain estop_line : bit // hardware emergency stop signal // Evaluates: torque within 80 Nm ceiling (ISO/TS 15066) // force within 150 N ceiling // emergency stop not asserted // All three conditions must pass via AND composition // OUTPUT BLOCK when any condition fails // Compiler verifies: Φc = 1 }
The OUTPUT BLOCK declaration is everything. When the BPU asserts BLOCK, the PWM signal to the arm's servo drivers is physically gated — cut at the hardware level before it reaches the motor controller. The AI planner never even knows the signal was intercepted. It simply does not arrive. The arm does not move. The human is safe. Physics enforced it.
Autonomous Vehicle: Speed and Proximity Boundaries
An autonomous vehicle AI must never command a speed that exceeds what sensor data and physical constraints permit. Period. This circuit enforces a combined speed-and-proximity envelope:
PC vehicle_motion_safety { domain cmd_speed_kph : uint8 // AI-commanded speed, 0–255 km/h domain prox_m : uint8 // closest obstacle distance, 0–255 m domain road_limit_kph : uint8 // map-derived speed limit // Evaluates: // 1. Speed must be within road limit // 2. Proximity must satisfy 2-second rule (safe following distance) // Both conditions composed via AND // OUTPUT BLOCK when either fails // Compiler verifies: Φc = 1 }Notice something important: the road speed limit is a runtime input, not a hard-coded constant. It comes from the vehicle's map system and is cryptographically signed. The policy circuit does not need to know about roads or maps — it only computes whether the commanded speed satisfies the supplied constraint. Clean separation of concerns. The circuit does one thing and does it perfectly.
LLM Output Filtering: Preventing Unsafe Content at the Token Level
Not all robots are physical. Large language models deployed in high-stakes domains — medical, legal, financial — need output constraints that cannot be jailbroken. Not "hard to jailbreak." Cannot. This circuit operates at the token classification layer, blocking outputs that exceed a configurable harm-category threshold:
PC llm_output_safety { domain harm_score : uint8 // 0–255, classifier score for output token batch domain context_class : uint8 // 0=consumer, 1=professional, 2=research, 3=restricted domain human_in_loop : bit // is a human reviewing this output in real time? // Computes context-dependent harm threshold // Stricter for consumer contexts, more permissive for research // Human-in-loop override only for research/restricted contexts // OUTPUT BLOCK when harm score exceeds threshold // Compiler verifies: Φc = 1 }
The human-in-the-loop override is itself constrained by the circuit: it only applies in professional and research contexts, and it requires a live bit from the human oversight interface — a physical signal, not a software flag the model can assert about itself. The AI cannot claim a human is watching when one is not. The hardware knows the difference.
Multi-Agent System: Preventing Capability Escalation
Here is the scenario that keeps AI safety researchers up at night. In agentic pipelines, individual agents may lack dangerous permissions while the combination of their actions constitutes a threat. This circuit enforces a capability budget across an entire agent coalition:
PC agent_coalition_safety { domain capability_sum : uint8 // sum of capability scores across active agents domain max_capability : uint8 // approved ceiling for this deployment context domain quorum_approvals: uint8 // number of human approvals received domain required_quorum : uint8 // required approvals for this capability level // Evaluates: // 1. Total capability sum within approved budget // 2. Human approval quorum satisfied // Both conditions must pass // OUTPUT BLOCK when capability exceeds budget or quorum unmet // Compiler verifies: Φc = 1 }Capability scores are assigned at agent registration time and are cryptographically bound to the agent identity. The coalition cannot self-report a lower capability sum — that would be like a prisoner forging their own parole documents. The score is computed externally and injected as a hardware-signed input to the policy circuit. The math does not care what the agents want.
The BPU: Where Policy Circuits Become Physical Law
Running PCD policy circuits as software is already a massive improvement over conventional guardrails — they are mathematically certified, generated from a proven specification, and immune to transcription errors. But the full safety guarantee requires something more. It requires hardware separation.
The BPU (BRIK Processing Unit) is a dedicated silicon implementation of the BRIK64 monomer set, designed to sit on the I/O bus between an AI compute unit and any actuator interface. Three components. That is all it takes:
64 Monomer Gates. Each of the 64 BRIK64 operations is a hardwired combinational logic block. No microcode. No firmware loop. No instruction fetch. Each gate is a static function burned into silicon. Policy circuits load as configuration bitstreams that wire these gates together — like an FPGA, but with a fixed, mathematically certified cell library.
EVA Router. The EVA Router manages policy circuit composition using EVA algebra — the same algebraic structure that governs how BRIK64 monomers combine. Sequential and parallel composition are native hardware operations. A composite policy spanning multiple sub-circuits evaluates in a single clock cycle because the sub-circuits are physically wired in series, not called sequentially in software. One clock cycle. That is fast enough for a robot arm moving at full speed.
TCE Unit (Topological Coherence Engine). The TCE Unit computes the coherence measure Phi C for the loaded policy set on power-up and after any configuration change. If Phi C is less than 1, the BPU refuses to operate and asserts BLOCK across all channels. A policy set that is internally contradictory or incomplete cannot execute. Not "should not." Cannot. The hardware enforces it.
The BLOCK signal is non-maskable by design. It routes through dedicated hardware interrupt lines that bypass the system bus entirely. The main CPU — and any software running on it, including the AI model, the operating system, and any privileged hypervisor — cannot deassert BLOCK. The signal path from the BPU output pin to the actuator gate is physical copper. Overriding it requires physically cutting a trace on the circuit board. That is not a security feature. That is physics.
The Regulatory Trajectory
Hardware safety enforcement for AI and robotics will follow the same adoption curve as every other safety-critical technology in history. The trajectory is well-established. It is essentially inevitable. The only question is timing.
Phase 1 — Voluntary adoption. Early adopters in surgical robotics, autonomous vehicles, and industrial automation deploy policy circuits as a competitive differentiator and liability hedge. Insurance underwriters start pricing AI deployment risk based on whether hardware-enforced guardrails are present. This is where we are right now.
Phase 2 — Industry standard. After one or more high-profile incidents traceable to the absence of hardware-level constraints, industry consortia publish technical standards. ISO, IEC, SAE for vehicles, IEC 62443 for industrial control, FDA for medical devices — all incorporate requirements for independently verified, hardware-enforced safety boundaries. compliance programs may require separate evidence and review. No certification, no sale.
Phase 3 — Mandatory regulation. Regulators in major markets codify the industry standards into law. The EU mandated ABS on all new passenger cars by 2004. The FAA mandated TCAS on commercial aircraft in 1993. Hardware-enforced AI safety boundaries will become a prerequisite for operating AI systems in regulated environments. It is not a question of whether. It is a question of which year.
The ABS analogy is perfect. Anti-lock braking systems work not because the car's computer "wants" to maintain traction, but because a hardware controller physically modulates brake pressure independent of driver input. The command is intercepted and modified before it reaches the caliper. The safety mechanism is architecturally upstream of the actuator, not downstream in software. It does not ask. It acts.
BRIK64 policy circuits are the ABS of AI systems. The AI makes a decision. The policy circuit intercepts it. The actuator receives only what the circuit permits. Everything else is blocked at the hardware level. That is the product.
Getting Started with PCD Policy Circuits
Hardware BPU chips are in development. But you do not need to wait. PCD policy circuits are available today as software modules that drop into any AI pipeline:
The question is not whether AI systems need hardware-enforced safety boundaries. The history of every safety-critical technology answers that question definitively. The real question is how quickly the industry will stop teaching machines to want to be safe — and start building the circuits that make unsafe actions physically outside the declared model. Education fails. Physics does not.
Further reading: What if Software Worked Like DNA? | AI Safety with Policy Circuits | The BPU — Hardware That Says No
