Inspiration :-In an emergency, asking for help may not be possible. A sudden incident can leave someone unable to reach their phone or explain what happened. Manual SOS only works if the user notices the danger and can act on it. We asked: what if a phone could recognize a possible emergency from contextual signals, not only from a button press
What it does :- SENTINEL is a context-aware safety workflow for moments when a user can’t ask for help. It follows four steps:
Observe: it uses available signals and user context. Assess: it evaluates whether the pattern suggests a possible emergency. Verify: it allows the user to confirm, when the workflow supports it. Communicate: it sends an emergency state and available details to the backend.
A web dashboard then shows what happened, why it was flagged, how serious it is, the last available location, and what happens next. For example, it might show “Possible vehicle incident” with the signals severe impact, sudden deceleration and abnormal movement. SENTINEL complements existing SOS tools rather than replacing them. Its core principle is to report evidence, not assumptions, so it says “possible incident” when an event isn’t confirmed.
How we built it :- SENTINEL is one system connected end to end:
Android app: captures signals and user input, and handles the trigger and verification flow. Backend/API: receives and validates events and applies access rules to sensitive data. Supabase: stores and retrieves incident records. Web dashboard: shows incident type, evidence, time, status and available location to authorized viewers.
The work was split three ways. E. Naren built the Android application, S. Monitha built the backend, Supabase and AI/risk layer, and M. Sushmitha built the dashboard and data presentation.
Before submitting, edit this section to match exactly what you built, such as which sensors are used and whether risk scoring is rules-based or AI.
Challenges we ran into :- Recognizing when a user can’t ask for help is harder than responding to a button press.
Combining several signals into one understandable alert, with event type kept separate from severity. Being honest about uncertainty, so a pattern isn’t presented as a confirmed emergency. Handling missing data such as unavailable location or no user response. Demonstrating the system safely with a simulated event, never a staged accident.
Accomplishments that we're proud of :-A clear working flow from signal to app event to backend record to dashboard view.
A dashboard that explains the event instead of showing only a severity label. A design that is upfront about its limits, which we think builds trust in a safety tool. Working together as a three-person team across the app, backend and dashboard.
What we learned :- In safety systems, context and clarity matter as much as the alert itself.
Combined signals are more meaningful than a single isolated value. Honest wording and clear limits matter when a system might affect someone’s safety. A smartphone-only system can’t guarantee an alert if no communication is transmitted.
What's next for SENTINAL NEXORA :- Improve false-alarm handling.
Strengthen authentication and access control. Explore independent communication redundancy for cases where the phone can’t transmit. Run controlled testing before any real-world deployment.
Log in or sign up for Devpost to join the conversation.