-
-
This is a high fidelity design for our app. We chose the color scheme to be purple in order to match Hack the Valley!
-
GIF
This is an impact graph taken recorded from a side fall. Thresholds were set in order to signal to the model that this classifys as a fall.
-
GIF
I had my airpods in to record the head acceleration and tilt from a side fall. This was used to train the fall detection model
-
GIF
Simulating a back fall, similar to what would happen in real life. I did around 50 of these to fully train the model properly.
-
GIF
This was a negative test where I sit down. This causes a head impact that could be classified as a fall but I explicitly set it to not do so
Inspiration
Concerts are loud, packed and rowdy. People get pushed, fall, get separated from friends or have a drink spiked, and in that moment they often can't reach their phone, let alone call for help. At the 2021 Astroworld festival, people crushed in the crowd at Travis Scott's set couldn't get help for themselves, and those around them didn't realise how serious it was until it was too late. We wanted a way to keep concert-goers safer in exactly those moments.
Project KAZE names the problem: the gap between someone becoming unable to ask for help and someone else realising they need it. Kaze means wind, the unseen presence that reaches for help when you cannot. Guardian is our answer: help that starts without the wearer doing anything, and that never claims to know what happened.
What it does
Guardian turns the AirPods people already wear at a concert into a safety check-in that only escalates if you stay silent.
Potential impact: closing the gap without the wearer acting
- It notices on its own. AirPods head tracking runs about 50 times a second. A fall (the head goes far from upright, then stays still), long stillness, or a scheduled check-in every 30 or 60 minutes starts a check-in. No button, no unlocking.
- Silence starts the chain. If the wearer doesn't answer, the server texts Contact 1, then Contact 2, then nearby responders, then venue staff, and opens an SOS screen on the wearer's phone.
- Help close by. Other Guardian users can opt in as nearby responders. If the wearer's own contacts don't respond, up to five opted-in responders within 250 m are texted at once, because in a crowd the closest help is often a stranger.
- A reason to keep the AirPods in all night. Guardian measures how loud the room is and raises noise protection as the night gets louder, so the sensor is there when it matters.
Safety and reliability: built around failure
- False alarms: a trained model, then three chances to cancel. We trained a fall model to tell real falls from the movements that look like them. It's a compact boosted tree (7 KB, on the phone) that scores every possible fall on 14 features of the head's motion. It was trained on our recorded couch falls and sit-downs, plus augmented variants and synthetic dancing. On held-out takes it caught 10 of 10 real falls, fired on 0 of 5 sit-downs, and fired 0 times in 30 minutes of simulated dancing. Even then it only fires after 10 seconds of stillness, and nobody is texted until the wearer has also missed a whisper, a louder prompt and a PIN gate.
- Missed signals. Scheduled and stillness check-ins catch what fall detection misses. The hand-tuned thresholds take over if the model ever fails to load.
- Connectivity failure. When a check-in starts, the phone registers a deadline with our server, and from then on the server holds the clock. The alert still goes out if the phone dies, loses signal or is taken. We proved it with the phone in airplane mode mid-countdown and with a real server restart mid-session.
- Unacknowledged alerts. Each recipient gets a window to acknowledge before the chain moves on.
- Misuse and coercion. A duress PIN looks identical to a safe cancel but silently alerts Contact 1. Three wrong PINs fire the alert, and a session can't be stopped mid-alert.
- Resolving false alarms. A contact can mark an alert resolved, and a late cancel from the wearer sends an all-clear to everyone already texted.
- No duplicates. A late cancel, a restart or a replayed request can't text anyone twice.
Usability and accessibility: the least effort first
- A nod cancels. Hands-free, no screen. Then a large Cancel button, then a PIN. That suits someone who is distressed, impaired or in a crush.
- Whisper first. A quiet prompt, louder only if needed, so a false alarm stays private.
- Contacts install nothing. Each text links to a mobile page with Acknowledge, Mark resolved, and a live location link that opens Google Maps at the newest position every time it's tapped.
Feasibility: off-the-shelf and running today
- Off-the-shelf parts. Apple's headphone motion API, Twilio SMS, and a Node server hosted on Railway. Real texts reached real phones in 1 to 2 seconds in our tests.
- The model lives on the phone. It needs no network to score a fall.
Privacy and autonomy: the wearer stays in control
- Nothing raw leaves the phone. No motion data or audio ever does. Location is sent only from the start of a check-in, and live only while an alert is open.
- Per-contact permissions, enforced on the server. The wearer chooses what each contact sees. Contact 1 might get location and what happened, while Contact 2 sees only a missed check-in.
- The duress record stays on the device, in a log that never leaves the phone.
- Nearby responders opt in. Their location is rounded to about 110 m, kept in memory only, and gone when they stop.
- It never dials 911 on its own. Guardian doesn't detect drugging, diagnose anyone or predict what happened. It notices that someone stopped answering and gets a person to check.
What's real, simulated and assumed
- Real: AirPods motion, the fall model, nod detection, voice prompts, the server countdown, real texts, live location and duress.
- Simulated: the emergency itself (falls from a Debug button or onto a couch), the SOS call (it dials a teammate), and the demo timings (texted at 20 s instead of 70 s).
- Assumed: the wearer has head-tracking AirPods in, and the phone is online when a check-in starts.
How we built it
- Wearer app: React Native (Expo) for the screens. A Swift native module handles AirPods head motion, the fall model and detectors, the check-in state machine, voice prompts, location and the server client, so it all keeps running with the screen locked.
- Fall model: Kean recorded falls and sit-downs. A Python script generates augmented variants, kept separate by source recording so none leaks between training and test. A training tool trains a Create ML boosted tree using leave-one-fold-out evaluation, and the app embeds it. A replay harness runs recorded motion through the exact code the phone runs.
- Escalation server: Node and Express on Railway over HTTPS. A one-second sweep runs over deadlines. A snapshot on a persistent volume lets pending alerts survive a restart, and the contact pages are rate-limited.
- Privacy filter: one server function decides what each recipient sees. The SMS, the contact page and the live map link all go through it, so they can't disagree.
- Testing: simulation only. Every scenario in the brief can be fired from a Debug screen. Over 1,400 automated tests cover the phone, app and server, including tests that fail if location or the duress record would leak.
Challenges we ran into
- Couch falls are soft. A detector tuned for hard floors misses them. We retuned on our own recorded falls, then trained the model to keep sit-downs and dancing out without missing real falls.
- A locked phone is hard to get location from. iOS won't start location from the background with only "while using" permission, so we hold an iOS background location session for the whole session.
- Real SMS needed real setup. Twilio's trial only texts verified numbers, so we upgraded, completed a compliance profile and bought a number.
- Production behaved differently from tests. Railway's data volume was owned by root, so saves silently failed, and its edge rotated client addresses, so our first rate limiter never limited anyone. We found both by testing on the hosted server.
- Making duress invisible. The duress and safe screens had to match in look and timing.
Accomplishments that we're proud of
- A trained fall model running on the phone. On held-out data, every real fall was caught and nothing fired on sit-downs or simulated dancing.
- The alert survives the phone. It kept going through airplane mode and a server restart.
- Per-contact privacy on real phones. Contact 1's and Contact 2's pages, side by side, show different information.
- A duress alert that the wearer's screen gives no sign of.
What we learned
- Design the failure first. Most of the value is in what happens when the phone, the network or a contact fails.
- Say what you don't know. Separating what's real, simulated, assumed and untested made a better system and a clearer demo.
- Test on the real stack. Several real bugs only appeared on the hosted server with real phones.
What's next for Guardian
- Train on more data. Many people, real dancing, lie-downs and hard floors. Our model learned from one person, so false alarms per hour at a real concert is the number we must measure next.
- Measure endurance. Nod detection with music at concert volume, a full locked night, and battery drain.
- Close our biggest gap. If the phone dies before a check-in starts, nothing escalates yet. A lost-contact watchdog is next.
- Pilot carefully. Test with consenting volunteers, then a small, informed pilot with venue staff.
Built With
- airpods
- core-motion
- expo.io
- express.js
- ios
- node.js
- python
- railway
- react-native
- sms
- swift
- twilio
- typescript
Log in or sign up for Devpost to join the conversation.