Safety that never fails quietly: isolating hazard detection from AI

The most important line in the Echo 1 codebase is a rule about what may not happen: the safety module may never import the assistant, any LLM, or any cloud client. Whatever else fails — the language model, the navigation engine, the dashboard — the user still hears 'Stop. Drop-off ahead.'

One process per service, one owner per sensor

Echo 1 runs as isolated subprocesses under a supervisor, communicating only over a ZeroMQ event bus. Each piece of hardware has exactly one owner: the safety service owns the camera and LiDAR, the audio service owns the speaker, the assistant owns the microphone. No shared memory, no resource fights, no lock contention on a serial port at the worst possible moment.

Priority on the only speaker

There is one speaker and everyone wants it. The Audio Manager arbitrates by priority: safety (100) preempts navigation (50) preempts the assistant (10). A hazard alert cuts off a turn instruction mid-word — by design.

Two layers of resurrection

• Layer 1 — the supervisor restarts any individual service that crashes, without touching the others.
• Layer 2 — if a critical service (safety or audio) cannot recover, the whole process exits non-zero and systemd performs a clean full-stack restart.
• An assistant, navigation, or vision crash never interrupts hazard alerts even for a second.

This is the pattern aviation and medical devices use, applied to a wearable: the life-safety path is small, boring, isolated, and unconditionally available. The clever AI features live outside it and are allowed to fail.