Skip to content
← All articles
Engineering1 min read

Two triggers, zero single points of failure: designing SOS

EchoSense fires SOS from two independent paths — an AI tool-call and a deterministic life-threat text detector — so emergency dispatch never depends on one system.

Every feature in EchoSense is allowed to fail except two: hazard alerts on the wearable, and SOS in the app. For SOS, the failure mode we engineered against is subtle — what if the moment of crisis is exactly the moment the clever system doesn't understand?

Trigger one: the model decides

Echo, the on-device AI, has an SOS tool it can call. If a conversation makes clear the user is in danger — reading context, history, and phrasing the way a language model can — Echo dispatches the alert. This path is smart: it catches indirect signals a keyword filter would miss.

Trigger two: the detector doesn't think

In parallel, a deterministic life-threat text detector scans messages for explicit danger signals. It has no model weights, no temperature, no context window — if the pattern matches, SOS fires. This path is dumb on purpose: it works even if the model misreads the situation, times out, or fails to load.

  • Either trigger alone is sufficient — dispatch is OR, not AND.
  • Dispatch reaches all linked caregivers with live location, on iPhone and Apple Watch.
  • The user can always trigger SOS manually — one tap in the app or on the watch.
  • Both triggers run on-device; the privacy architecture holds even during an emergency.

Tuning the tradeoff

Redundant triggers raise the false-positive risk, so each is tuned conservatively on its own — but their union keeps sensitivity high where it counts. A false SOS costs an awkward phone call. A missed one is unacceptable. The asymmetry decides every threshold.

The same philosophy runs through the wearable: safety logic stays isolated from AI. Redundancy is only real when the paths share no dependencies.

Questions about EchoSense, pilots, or partnerships?

Talk to the team