SafetyFirst

Elevator Pitch

Navigation apps don’t fail at the start of a route. They fail after you’ve already committed. A path that looks safe can suddenly turn dangerous halfway through, with no warning and no clear next step. That’s because navigation systems treat safety as a one-time decision. Traditional navigation reacts after a route fails. SafetyFirst predicts when it will fail before you reach it. We model a route as a sequence of safety states, not a single path. By continuously analyzing each segment, we detect the exact moment a route becomes unsafe, explain why it happened, and surface a safer alternative before the user reaches danger.

Inspiration

This started from a real experience during a Microsoft internship. One of us followed a route that looked completely normal until it suddenly became unsafe midway, with no way forward. That revealed the real problem: Navigation doesn’t fail when you choose a route. It fails when the route stops being safe to continue.

What It Does

SafetyFirst continuously evaluates a route as you move through it. Instead of labeling an entire route as “safe” or “unsafe,” we: break the route into segments attach safety signals to each segment compare adjacent segments to detect safety breakdowns We detect failures like: sidewalks disappearing residential streets turning into high-speed roads increased pedestrian exposure sudden transitions from low-risk to high-risk conditions When that happens, SafetyFirst: pinpoints the exact failure location explains what changed highlights the last safe point surfaces a safer alternative route or fallback option In our tests on real routes, SafetyFirst consistently flags unsafe transitions before users reach them, something traditional navigation does not explicitly surface.

How we Built it

We built SafetyFirst as an end-to-end system combining real route data, segment modeling, and sequential safety reasoning.

Real route ingestion We use the Google Routes API to generate walking routes and decode them into ordered segments.
Segment-based modeling Each route is represented as a sequence of segments with interpretable features: risk level road type (residential vs arterial) trail vs roadway lighting and crossings
Transition-based failure detection Instead of scoring a route once, we compare each segment with the previous one. A safety failure is defined as a meaningful degradation between adjacent segments. We implemented this using rule-based Python logic, for example sidewalk to no sidewalk and residential to primary road, then modeled it in Jaseci (Jac): routes as connected segment nodes a safety_walker traverses the route detects risk increases records failure points and last safe segments
Intervention logic When a failure is detected, we recommend safer alternatives: lower-risk walking paths fallback options when continuation is unsafe
Backend system A FastAPI backend: serves route data runs safety analysis integrates with the Jac agent returns structured outputs such as failure point, reason, and intervention Example: A walkable residential path transitions into a high-speed road with no safe crossing. SafetyFirst: detects the unsafe transition before the user reaches it flags the exact failure segment highlights unsafe portions in red surfaces a safer alternative in green

Challenges we Ran into

Real-world map data is messy. Sidewalk data is often incomplete, so relying on a single feature was not reliable. We learned: Safety is not about one feature. It is about how conditions change along a route. Shifting to transition-based detection made the system more robust and explainable.

Accomplishments we are Proud of

Built a real working system on actual route data that pinpoints the exact moment safety breaks instead of just flagging routes as unsafe. It captures the last safe point before failure, explains clearly why the failure happens, and presents that reasoning in a way that is easy to understand. It also surfaces safer alternatives both visually and programmatically, so instead of a vague “this route is unsafe,” it shows exactly where it fails, why it fails, and what to do next.

What we Learned

Execution details matter just as much as the idea. Managing merges, keeping the pipeline in sync, and ensuring each component communicated correctly was a constant challenge. Small inconsistencies could break the system. We also hit hard limits with data quality. OpenStreetMap sidewalk data was too inconsistent for reliable detection, which forced us to rethink our approach instead of patching a weak signal. Another key lesson was data precision. Standard route segments were not granular enough to identify exactly where safety breaks. Switching to the Google Routes API gave us finer-grained geometry, allowing us to pinpoint true failure points. Most importantly, we learned to recognize when an approach is not working and pivot quickly instead of forcing a solution on top of bad data.

What’s Next

We’re scaling SafetyFirst from a route analysis tool into a continuous safety layer for navigation systems. Today, we evaluate safety across a single route by modeling it as a sequence of segments. The next step is scaling this pipeline to operate on any route in real time as the user progresses. To do that, we plan to: integrate with platforms like Google Maps or Mapbox to ingest and segment live routes attach safety signals at scale using road type, traffic exposure, crossings, and environmental context run continuous transition-based evaluation during navigation We also plan to expand beyond pedestrian safety. The same model can apply to: driving scenarios such as sudden road condition changes or hazard zones real-time risks including weather, lighting, and temporary disruptions Long term, our goal is to move navigation from static route planning to continuous safety monitoring, where routes are not just generated once, but actively evaluated as conditions change.