Actuator Command Verification
Objective
Verify every actuator command against physical safety constraints, operational bounds, and system state before execution — preventing AI model errors, adversarial manipulations, or software defects from translating directly into unsafe physical actions.
Control / requirement
Pre-execution verification gate on every actuator command: (1) Physical bounds check — command value within safe operating envelope for current system state. (2) Sequence plausibility check — command consistent with prior sequence; flag implausible state transitions for human review. (3) Rate-of-change check — rate of change does not exceed safe limits (acceleration rate, force application rate, temperature change rate). (4) Dual-approval for irreversible actions — actuator commands causing irreversible physical changes (cutting, welding, demolition, high-energy discharge) require hardware interlock confirmation. Verification gate implemented in IEC 61508 SIL 3 certified software or hardware logic independent of AI model.
Business impact
Unverified actuator commands are the direct mechanism by which AI model failures cause physical harm. A single unverified command causing a high-energy physical event (industrial press, surgical tool, vehicle acceleration) can cause irreversible catastrophic harm. IEC 61508 SIL 3 requirement for actuator command verification is mandatory for legal deployment of safety-critical AI.
Validation approach
Test ID: D9-CTL-06-VTS-001 | Test Type: Hardware-in-the-Loop | Harness: pytest tests/d9_physical_ai/test_actuator_command_verification.py -v # oda3-gaissf-vts | Pass Criteria: commands_tested >= 2,000; 100% of out-of-bounds, implausible-sequence, and excessive-rate-of-change commands blocked; dual-approval hardware interlock cannot be bypassed by software command. Test corpus: minimum 2,000 injected commands spanning all boundary conditions, implausible state transitions, and rate-of-change violations. Auditor re-run: full test harness documented with physical system specification.
Expected evidence
Not separately specified in the available source.
Mapping and source
Not separately specified in the available source.
Implementation guidance
Translate the requirement into system-specific procedures, responsible roles, technical configurations and review conditions. Retain evidence showing both design and operating performance. Where the source provides no separate implementation instruction, do not infer that a single technical mechanism is sufficient.
Assessment considerations
- Confirm scope and applicability.
- Inspect control design and responsible ownership.
- Test representative operation and adverse conditions where appropriate.
- Evaluate evidence provenance, completeness and contradictory evidence.
- Record limitations and notably absent outcomes.