A surprising number of safety procedures quietly assume that a human is present. A driver may place
warning devices around a stopped vehicle, move equipment away from a blocked path or verbally
explain a problem to other road users. When the machine is genuinely unmanned, copying the old
procedure may be impossible.
The right response is not to remove the safety objective. It is to separate the objective from its historical
implementation. The objective may be visibility, isolation, pedestrian clearance, secure custody or rapid
recovery. A robot can then use a machine-native fallback such as high-visibility signals, an automatically
selected safe-stop location, remote escalation or a controlled fleet-wide pause.
Regulatory acceptance depends on evidence. The operator should record why the fallback activated,
where it occurred, how long it lasted, which warning was displayed, whether remote assistance was used
and how the situation ended. Results must be normalized against missions, hours or distance so that
authorities can interpret risk rather than receive an isolated incident count.
This principle applies beyond public roads. An indoor delivery robot encountering a fire alarm, elevator
failure or locked door also needs a defined minimal-risk state. The safest behaviour may be to return,
pull over, preserve an accessible route or secure the payload until an authorized person arrives.
Designing these fallbacks early turns regulatory compliance into a system capability. It also prevents
emergency behaviour from becoming an improvised remote-operator decision.
Fainzy perspective
Fainzy could create a machine-native fallback library for ZiBOT and MiraX covering localization loss,
communication loss, propulsion faults, blocked routes and compromised cargo. This is a proposed
safety-development framework and should be validated through hazard analysis, testing and the
applicable authority or site owner.