AI Guardrails for Robots

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 and revise its own outputs.

For language models generating text, this approach is reasonable. For AI systems that control physical hardware — robot arms, autonomous vehicles, surgical devices, industrial actuators — it is not enough. 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 its 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 human.

Safety-critical engineering has understood this for decades. We don't rely on aircraft engines "wanting" to stay within temperature limits. We install physical thermal cutoffs. We don't trust a car's ECU to "choose" not to accelerate beyond a safe speed — we build transmission governors. The mechanism that prevents the bad outcome is separate from, and independent of, the system being constrained.

BRIK-64 and PCD (Printed Circuit Description) bring this same architectural separation to AI systems and robotics through policy circuits— deterministic, formally verified, hardware-enforceable constraints that sit between an AI's decisions and the physical world.

What a Policy Circuit Is

A policy circuit is a small PCD program that evaluates a proposed action against a set of 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 a binary result: ALLOW or BLOCK.

Policy circuits are composed exclusively from the 64 atomic monomers of BRIK-64. This is not an arbitrary limit. 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 formally verified in Coq. There are no undecidable edge cases, no runtime exceptions, no floating-point ambiguity. The circuit computes what it is proven to compute, every time.

When deployed on a BPU (BRIK Processing Unit)— a dedicated hardware chip 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.

Policy Circuit Examples

Robot Arm: Force and Torque Limits

A collaborative robot arm operating near humans must never exceed safe force thresholds regardless of what the AI planner commands. 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 BLOCKdeclaration is the key. 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.

Autonomous Vehicle: Speed and Proximity Boundaries

An autonomous vehicle AI must not command a speed that exceeds what sensor data and physical constraints permit. 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 that 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. The concerns are separated by design.

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. 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: 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.

Multi-Agent System: Preventing Capability Escalation

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 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. The score is computed externally and injected as a hardware-signed input to the policy circuit.

The BPU: Where Policy Circuits Become Physical Law

Running PCD policy circuits as software is already a significant improvement over conventional guardrails — they are formally verified, generated from a proven specification, and immune to transcription errors. But the full safety guarantee requires hardware separation.

The BPU (BRIK Processing Unit) is a dedicated silicon implementation of the BRIK-64 monomer set, designed to sit on the I/O bus between an AI compute unit and any actuator interface. Its architecture has three main components:

64 Monomer Gates. Each of the 64 BRIK-64 operations is implemented as a hardwired combinational logic block. There is no microcode, no firmware loop, no instruction fetch. Each gate is a static function burned into silicon. Policy circuits are loaded as configuration bitstreams that wire these gates together — analogous to an FPGA, but with a fixed, formally verified cell library.

EVA Router. The EVA Router manages the composition of policy circuits using EVA algebra — the same algebraic structure that governs how BRIK-64 monomers combine. Sequential composition and parallel composition are native operations at the hardware level. 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.

TCE Unit (Topological Coherence Engine). The TCE Unit computes the coherence measure Φ_c for the loaded policy set on power-up and after any configuration change. If Φ_c< 1, the BPU refuses to operate and asserts BLOCK across all channels. This is the hardware equivalent of the genetic code's error-correction: a policy set that is internally contradictory or incomplete cannot execute.

The BLOCK signal itself is non-maskable by design. It is routed 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.

The Regulatory Trajectory

Hardware safety enforcement for AI and robotics will follow the same adoption curve as every other safety-critical technology in industrial and consumer systems. The trajectory is well-established and essentially inevitable.

Phase 1 — Voluntary adoption. Early adopters in high-stakes verticals — surgical robotics, autonomous vehicles, industrial automation — deploy policy circuits as a competitive differentiator and liability hedge. Insurance underwriters begin pricing AI deployment risk based on whether hardware-enforced guardrails are present. This is where we are today.

Phase 2 — Industry standard. Following one or more high-profile incidents traceable to the absence of hardware-level constraints, industry consortia publish technical standards for AI safety enforcement. ISO, IEC, and domain-specific bodies (SAE for vehicles, IEC 62443 for industrial control, FDA for medical devices) incorporate requirements for independently verified, hardware-enforced safety boundaries. Compliance becomes a procurement requirement.

Phase 3 — Mandatory regulation. Regulators in major markets codify the industry standards into law. Just as the EU mandated ABS on all new passenger cars by 2004, or the FAA mandated TCAS on commercial aircraft in 1993, hardware-enforced AI safety boundaries become a prerequisite for operating AI systems in regulated environments. Certification bodies emerge to verify policy circuit implementations.

The analogy to ABS is instructive. 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 driver's command is intercepted and modified before it reaches the caliper. The safety mechanism is architecturally upstream of the actuator, not downstream in software.

BRIK-64 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.

Getting Started with PCD Policy Circuits

Hardware BPU chips are in development. But PCD policy circuits are available today as software modules that can be integrated into any AI pipeline:

# Compile a policy circuit to Python
brikc emit python policies/robot_arm_safety.pcd -o arm_guardrails.py

# Run TCE coherence certification
brikc certify policies/robot_arm_safety.pcd
# TCE: Φ_c = 1 ✓ — Policy set is coherent and complete

# Generate Coq proof obligations
brikc prove policies/robot_arm_safety.pcd -o proofs/arm_safety.v

Even as software, formally verified policy circuits provide stronger guarantees than hand-written guards: they are proven correct by construction, generated from a specification rather than written ad hoc, and carry a machine-checkable coherence certificate. When BPU hardware ships, the same PCD source compiles to a silicon bitstream with no changes to the policy logic.

The question is not whether AI systems need hardware-enforced safety boundaries. The history of every safety-critical technology answers that question. The 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 impossible.

Further reading: What if Software Worked Like DNA? | AI Safety with Policy Circuits | The BPU — Hardware That Says No