There is a quiet architectural decision that separates safety products that work from safety products that perform: where does the authority live? If critical decisions — who may see a victim's location, who counts as an accepted responder, what an alert's state is — are computed on the phone, then anyone who controls a phone controls your safety system.
The threat model is not hypothetical
In a community-response platform, the dangerous user is not a hacker in the abstract — it could be a stalker attempting to see a victim's live location without accepting responsibility, a bad actor spoofing responder acceptance, or a modified client replaying stale coordinates. Every one of these attacks targets client-trusted logic.
Guardian's rule: privileged actions go through the server
In Guardian, responder actions — accepting an alert, unlocking a victim's precise location, recording an approach — execute inside server-side Cloud Functions. Firestore security rules default to deny; the client cannot write itself into a privileged state. Accepting an alert is what unlocks location, and that acceptance is recorded server-side, creating accountability by construction.
The same math on both sides
Authority on the server does not mean opacity for the responder. Guardian's client map uses byte-for-byte the same destination-point formula as the dispatch engine, so what a responder sees is exactly what the server computed — verified consistency instead of trust.
Fast AND correct
The usual objection is latency. In practice, a well-designed function path adds milliseconds — a rounding error against the minutes that dispatch precision saves. Safety systems should be fast; they must be correct. Server-authoritative design is how you get both without pretending.