Safety Interlock

The interlock's logic must be hardwired or implemented in a separate, non-bypassable circuit or process, independent of the agent's own reasoning core. This ensures that even if the agent's cognitive architecture is compromised, the interlock remains effective.

• Physical separation: In hardware, this means a dedicated safety relay or PLC that physically breaks a circuit.
• Process isolation: In software, this means a separate, minimal-privilege daemon that the agent cannot signal or modify.
• No software override: The agent must not have the API or permission to disable the interlock's logic path.

A safety interlock must operate in a fail-safe or positive mode, meaning the default state is the safe, restricted condition. Energy or a continuous "okay" signal must be actively applied to permit the dangerous action.

• Normally open contacts: In a physical interlock, the circuit is open (safe) until all conditions are met and the relay is energized.
• Liveness signal: A software interlock requires a continuous, cryptographically signed heartbeat from all safety sensors. If the signal stops, the action is blocked.
• Contrast with fail-open: A fail-open design would allow the action if the interlock fails, which is unacceptable for safety-critical systems.

The set of safety preconditions must be evaluated using deterministic, Boolean logic, not probabilistic machine learning models. The interlock's decision must be provably correct and auditable in real-time.

• Explicit thresholds: Conditions like robot_arm_angle < 180 or pressure_sensor_psi < 100 are unambiguous.
• No black-box models: An LLM or neural network should not be the final gatekeeper for a safety-critical action due to their non-deterministic nature.
• Formal verification: The interlock's logic should be simple enough to be formally verified for all possible input states.

The interlock must rely on independent, redundant sensors that are separate from the agent's primary perception pipeline. This prevents a single sensor failure or a perception model hallucination from creating a false sense of safety.

• Sensor diversity: Use different physical principles (e.g., a mechanical limit switch and an infrared beam) to detect the same hazardous condition.
• Cross-validation: The interlock's logic should require agreement from multiple independent sensors before deeming a condition safe.
• No reliance on agent state: The interlock should not trust the agent's own reported position or status; it must measure reality directly.

Any attempt to bypass, disable, or modify the safety interlock must be immediately evident and logged immutably. The interlock's status and decision history must be auditable for post-incident analysis.

• Immutable logging: All interlock state changes, sensor readings, and decisions are written to a write-once, read-many (WORM) log.
• Physical tamper seals: Hardware interlocks should have physical seals or enclosures that show visible damage if accessed.
• Cryptographic integrity: Software interlock code and configuration should be signed, and any unauthorized change must invalidate the signature and trigger a safe state.

The interlock system must have the smallest possible attack surface. It should run on minimal hardware or within a unikernel, expose no network ports, and accept only the specific, signed inputs it requires to function.

• Air-gapped operation: The ideal interlock has no network interface at all, receiving inputs only from directly wired sensors.
• Stripped-down OS: If a software interlock requires an OS, it should be a minimal, hardened real-time operating system (RTOS) with all unnecessary services removed.
• No user interface: The interlock should have no interactive shell, API, or configuration interface accessible during operation.

A hardwired safety circuit that physically breaks the electrical connection to actuators, motors, or effectors, independent of any software state. These are the highest-integrity interlocks because they cannot be overridden by a compromised or malfunctioning agent.

• Example: A robotic arm's joint motor power is routed through a light curtain sensor relay; if the beam is broken, power is physically disconnected at the contactor.
• Key Principle: Implements a fail-safe state by defaulting to de-energized.
• Common in: Industrial robotics (ISO 13849), autonomous mobile robots (AMRs), and CNC machinery.

A programmatic precondition check that executes in a trusted, separate process or enclave before an agent's action command is forwarded to an actuator or API. This creates a logical air gap between the decision-making model and the physical world.

• Mechanism: The agent proposes an action; the interlock validates it against a formal safety specification (e.g., torque limits, geofences, rate of change limits).
• Example: An autonomous drone's flight controller rejects a motor command that would exceed a hard-coded maximum altitude, even if the navigation model demands it.
• Critical for: Preventing reward hacking where an agent discovers an unsafe but policy-compliant shortcut.

A safety interlock that defines a multidimensional boundary of acceptable operation and prevents the agent from executing any action that would breach it. This is a dynamic interlock that adapts to real-time sensor data.

• Dimensions enforced:
  • Spatial: Geofencing, joint angle limits, no-fly zones.
  • Kinetic: Maximum velocity, acceleration, and force/torque ceilings.
  • Thermal: Motor winding temperature limits, battery thermal runaway thresholds.
  • Temporal: Time-of-day operation restrictions, maximum continuous run time.
• Example: A quadruped robot's locomotion controller is interlocked to refuse any gait that would exceed a safe ground reaction force, preventing it from kicking a nearby human.

An interlock that requires a verifiable cryptographic signature from an authorized human operator or a separate safety-rated controller before a high-hazard action is executed. This prevents an agent from unilaterally initiating dangerous operations.

• Workflow:
  1. Agent requests permission to execute a classified hazardous action (e.g., laser firing, high-voltage discharge).
  2. The interlock halts execution and sends a signed challenge to a human operator's hardware token.
  3. Only a valid Ed25519 signature from the token releases the interlock.
• Use Case: Autonomous surgical robots requiring surgeon confirmation before making an incision. Autonomous weapon systems requiring a human 'in-the-loop' for lethal force authorization.

A voting-based safety architecture where two or more independent, dissimilar systems must agree before an action is permitted. If a single channel disagrees or fails silent, the interlock trips to a safe state.

• Architecture:
  • Channel A: The primary AI agent's action proposal.
  • Channel B: A simple, formally verified safety controller analyzing the same sensor data.
  • Interlock Logic: A hardware comparator (e.g., a safety PLC) requires consensus. A mismatch triggers an immediate emergency stop.
• Example: In autonomous driving (ISO 26262 ASIL-D), a primary perception model and a secondary radar-based safety channel must both agree the path is clear before a lane change is executed.

An interlock that uses external sensor data to block agent actions when the physical environment is outside safe operating parameters, regardless of the agent's internal state or intent.

• Sensors monitored:
  • Presence Detection: LiDAR, safety mats, and light curtains detect humans in the agent's work envelope.
  • Atmospheric: Gas sensors prevent operation in explosive atmospheres.
  • Structural: Strain gauges on a drone's airframe prevent high-G maneuvers if micro-cracks are detected.
• Example: A collaborative robot (cobot) uses a skin-based capacitive sensor; if it detects contact with a human, the interlock instantly cuts motor torque to near-zero, allowing a harmless collision.