DEV Community: Isha Gautam

UNREACHABLE: What If an Emergency Vehicle Knows the Address but Cannot Reach the Building?

Isha Gautam — Sun, 25 Oct 2026 21:15:49 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Imagine calling an ambulance or the fire service during an emergency. You provide the address. The location is correct. The route looks reasonable on a map.

But there is a problem: the vehicle reaches the neighbourhood, yet cannot physically reach the building.

A narrow lane, illegally parked vehicles, construction material, a blocked entrance, or insufficient turning space can turn the final stretch of a journey into a serious obstacle. Knowing where an emergency is happening does not necessarily mean knowing how to reach it.

That is the problem I am exploring with UNREACHABLE — an AI-powered emergency accessibility intelligence platform.

The idea began with a simple question:

What if emergency navigation could tell us not only where a building is, but also whether an emergency vehicle can plausibly reach it?

UNREACHABLE is designed to connect street-level accessibility evidence with road-network analysis. Instead of treating every mapped road as automatically usable, it aims to help identify potential access constraints, understand which buildings may be affected, and prioritize improvements that could make a real difference.

The platform is built around five connected capabilities:

Access Atlas: A map-based view of buildings, roads, emergency facilities, and potential bottlenecks. It brings accessibility information into one place instead of leaving it scattered across separate observations.
AI Access Inspector: An AI-assisted way to examine street photographs and identify potential obstructions, such as parked vehicles or construction material. These are observations that can be reviewed by a human—not automatic declarations that a road is unsafe or impassable.
Vehicle-Aware Route Analysis: An approach to assessing road-network reachability against a selected emergency vehicle's constraints, using available road data and explicitly defined rules.
Bottleneck Impact Simulation: A way to explore a hypothetical question: if a constrained road segment were cleared or improved, which additional buildings might become reachable through the network?
Fix-First Prioritization: A way to help identify which constraints deserve investigation first, based on factors such as affected buildings, severity, alternative access, and the freshness of the evidence.

These capabilities are intended to work together. The goal is not simply to mark a road as blocked. It is to connect a possible obstruction to the buildings that depend on that road and make the potential consequences easier to understand.

The people who could benefit include emergency planners, municipal authorities, urban planners, and communities working to improve local emergency access.

UNREACHABLE is intended to complement existing maps and emergency-response systems, not replace dispatchers, emergency personnel, or on-site verification.

Code

GitHub repository: https://github.com/shiriei/UNREACHABLE

The project is being developed as a modular application, with the frontend, backend, sample geospatial data, and technical documentation separated so the components can evolve independently.

The goal is to make the reasoning behind an accessibility assessment understandable and inspectable, rather than hiding every decision behind an AI-generated result.

I also want the project to be useful as a foundation for future contributors: additional neighbourhood datasets, better vehicle profiles, improved obstruction verification, and more reliable road-network information should be possible to add without rebuilding the entire application.

How I Built It

I approached UNREACHABLE as a combination of geospatial analysis, conventional software engineering, and AI-assisted visual inspection.

The important design decision was to give each technology a specific job instead of asking AI to make every decision.

1. The application layer

The planned application architecture uses:

React, TypeScript, and Vite for the frontend.
FastAPI and Python for backend services.
GeoJSON for representing sample buildings and road-network features.
Geospatial and graph-analysis tools, such as Shapely and NetworkX, for geometry checks and road-network reachability where the available data supports them.
OpenAI vision capabilities for identifying potential access-related observations in uploaded street photographs.

The architecture is modular because the interface, geospatial logic, and AI analysis have different responsibilities and should be testable independently.

2. Why AI belongs in this project

AI is useful here because photographs can contain visual clues that are difficult to capture through a simple list of road attributes.

A street image might show a parked vehicle occupying part of a lane, construction material near an entrance, or a passage that appears particularly constrained. A vision model can help turn those visual clues into structured observations that a person can review.

For example, an observation could record:

The potential obstruction detected.
The visible evidence supporting that observation.
The location associated with the photograph, when provided.
The observation time, when available.
A verification status indicating whether a person has reviewed it.

This makes visual evidence easier to organize and connect to the map.

However, a photograph alone cannot reliably establish the exact width of a road, the current condition of an entire route, or whether a particular emergency vehicle can pass. Perspective, occlusion, image quality, and changing street conditions all matter.

That is why the intended workflow is AI observation → human verification → accessibility assessment, rather than AI prediction → unquestioned decision.

3. Why conventional algorithms still matter

A vision model can identify a possible obstruction, but it should not be responsible for inventing a route.

Road-network analysis handles a different question: given the road connections, known constraints, selected vehicle profile, and available evidence, which buildings have a feasible path under the system's rules?

A graph represents road segments and their connections. Constraints can be associated with individual segments. Reachability can then be recalculated when a segment is treated as constrained or hypothetically restored.

The impact of a proposed improvement can be expressed as:

Impact of a constraint = buildings reachable after the hypothetical improvement − buildings reachable before it.

This is an estimate produced under stated assumptions, not a measurement of real-world outcomes.

The analysis must also account for missing information. If road width, vehicle requirements, access restrictions, or network connections are unknown, the system should report Unknown where appropriate instead of silently assuming that access is possible.

4. Making the result actionable

A map full of warning markers is not enough.

UNREACHABLE is designed to help answer three practical questions:

What is the potential access problem?
Which buildings might depend on the affected road segment?
What could change if that constraint were investigated and resolved?

The prioritization layer can help organize these questions using transparent criteria, rather than presenting an unexplained AI-generated ranking.

The broader ambition is to move from seeing a problem to understanding its potential network impact.

Why Does Open Innovation Matter?

Emergency accessibility is a local problem with local details.

A road constraint in one neighbourhood may be caused by informal parking. Somewhere else, it may involve construction, a gated entrance, a sharp turn, or an incomplete road map. A solution that works with one dataset or one city's assumptions may not work everywhere.

That makes openness especially valuable.

First, the evidence can be challenged. Accessibility assessments should not be unquestionable outputs from a black box. Developers and domain experts should be able to inspect the underlying road data, assumptions, and reasons behind a result.

Second, communities can contribute local knowledge. Residents and local authorities may know about recurring obstructions or access restrictions that are missing from map data. A future version could incorporate structured reports with timestamps, location information, verification, and expiry rules so outdated reports do not remain authoritative indefinitely.

Third, the approach can be adapted. Different emergency vehicles and neighbourhoods have different requirements. An open, modular system makes it easier to introduce new vehicle profiles, datasets, and validation rules.

Fourth, independent contributors can improve individual parts. One contributor could work on geospatial reachability, another on visual-observation review, and another on accessibility-data quality, without requiring everyone to understand the entire codebase.

Open innovation does not automatically make a system accurate, and an open-source model is not automatically better than a closed one. The value here is the opportunity to make the overall approach more transparent, adaptable, and open to scrutiny.

For a project involving emergency access, that scrutiny is essential.

My Agent Session

[Optional: Add your DevRelay agent session link or embed your session here if you recorded one.]

During development, I have been breaking the project into manageable phases rather than attempting to build a complete emergency-response platform in one step. This helps keep the architecture understandable, makes individual features easier to validate, and reduces the risk of presenting unfinished functionality as a working capability.

The Lazy Payoff

The kind of work I want UNREACHABLE to reduce is the repetitive effort involved in piecing together accessibility information from separate maps, street observations, and road records.

Imagine a planner investigating a constrained road. Without a connected analysis workflow, they may need to inspect the road, identify the buildings beyond it, compare possible approaches, and manually reason about what might happen if the road were cleared.

UNREACHABLE aims to bring those steps into one workflow:

Identify a potential bottleneck → inspect the evidence → assess affected buildings → simulate an improvement → prioritize further investigation.

That does not eliminate the need for field inspections or professional judgment. It helps people spend less time connecting disconnected pieces of information and more time investigating the constraints that matter.

I am not claiming a measured time saving yet. Establishing that would require testing the workflow with real users and comparing it with their existing process. For now, the payoff is the opportunity to make an otherwise complicated analysis more visible, repeatable, and easier to discuss.

What Makes UNREACHABLE Different?

Road mapping, routing, computer vision, and geographic analysis already exist individually. I do not claim to have invented those technologies.

The innovation I am pursuing is their combination around a specific question: can the selected emergency vehicle plausibly reach this building, based on the evidence currently available?

Three ideas define that direction:

Building-level consequences: Move beyond marking a road constraint to understanding which buildings may be affected by it.
Evidence-connected AI: Use visual AI to produce reviewable observations, not unsupported declarations of passability.
Explicit uncertainty: Distinguish verified access, constrained access, likely inaccessibility, and unknown access instead of treating missing data as proof of safety.

Together, these ideas aim to make emergency accessibility more understandable and more actionable.

Challenges and Lessons Learned

One of the biggest challenges is that a map is not the same thing as reality.

A road can appear connected in a dataset but be too narrow for a particular vehicle. A photograph can reveal a possible obstruction without showing the entire passage. A route that works for a car may not work for a fire tender. And an obstruction reported yesterday may have disappeared today.

These are not minor edge cases; they shape the system's design.

I have therefore treated data quality, human verification, vehicle-specific constraints, and explicit uncertainty as core requirements rather than features to add at the end.

Another challenge is scope. A citywide system with live reports, reliable vehicle specifications, verified road measurements, and operational emergency-service integration would require substantial data collection, validation, and partnerships. A hackathon prototype cannot honestly claim to have solved all of that.

The practical approach is to start with a clearly labelled sample neighbourhood, demonstrate the analysis end to end, make the assumptions visible, and build toward validation with real data.

What's Next?

The next steps are to strengthen the end-to-end workflow:

Improve the quality and provenance of road and building data.
Make the vehicle constraints and reachability rules explicit.
Connect AI observations to a review and verification workflow.
Test bottleneck simulations against carefully constructed scenarios.
Evaluate the interface with people who understand emergency access and urban planning.
Explore a small real-world pilot only when suitable data and expert validation are available.

The long-term vision is a tool that helps communities and planners identify potential emergency-access barriers before those barriers become critical during a real incident.

Prize Categories

Best use of GEMMA

UNREACHABLE starts with a simple principle:

Knowing where an emergency is happening is only part of the problem. We also need to understand whether help can physically get there.

The aim is not to let AI make emergency decisions. It is to help people see potential access barriers, understand their consequences, and investigate possible improvements with better evidence.

Because a destination on a map should never be confused with a guarantee of access.

UNREACHABLE: AI-Powered Emergency Accessibility Intelligence Platform

Isha Gautam — Sun, 18 Oct 2026 15:19:53 +0000

Submission for Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

What I Built

UNREACHABLE addresses a critical gap in emergency response planning: knowing a building’s location does not guarantee that an emergency vehicle can reach it.

The platform aims to identify road bottlenecks, assess vehicle-specific accessibility, analyze street images for potential obstructions, and estimate the impact of infrastructure improvements.

Potential users include emergency services, municipal authorities, and urban planners who need better information to prioritize access issues.

Demo

http://drive.google.com/file/d/1WSaQ2wPVNFKtvxH-kamM_aK3rJC_LmAl/view

Code

https://github.com/shiriei/UNREACHABLE

How I Built It

UNREACHABLE combines a web-based mapping interface with geospatial analysis and an AI-assisted visual inspection workflow. The planned architecture uses React and TypeScript for the frontend, FastAPI for backend services, GeoJSON for spatial data, and OpenAI vision capabilities to identify potential obstructions in street photographs.

The system is designed to distinguish verified information from uncertain findings, keeping human review central to safety-critical decisions.

Why Does Open Innovation Matter?

Emergency accessibility is a shared infrastructure problem, not a problem any single organization can solve alone.

Open innovation enables developers, researchers, and civic authorities to improve mapping data, validate detection methods, and adapt the platform to local road conditions. It also makes the approach more transparent, extensible, and accessible to communities that need it most.

Prize Categories

Best use of Gemma

I Taught Local AI to Help Me Notice the World.

Isha Gautam — Sat, 10 Oct 2026 01:54:46 +0000

Your World Is More Interesting Than Your Feed.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What if the things you noticed on a walk mattered more than the posts you scrolled past?

A strange-looking plant. An interesting rock. The sound of birds from a place you've never stopped to notice. Tiny details we usually walk past without a second thought.

That's the idea behind TRACE.

TRACE is a map-based exploration app that turns real-world observations into a personal, AI-assisted record of the world around you. It encourages you to step outside, pay attention, capture what you find, and slowly build a map of your own discoveries.

The goal isn't to spend more time in an app. It's to give you a reason to spend more time noticing the world outside it.

🌍 What I Built

TRACE combines real-world exploration, multimedia capture, local AI, and a little gamification to make curiosity a habit.

Here's what you can do with it:

🗺️ Trace Map: Explore observations on an interactive map and see the world through the things people notice.
📍 Trace Capture: Create observations with text, photos, or audio. Attach a location using GPS or place it manually on the map.
🧠 Local AI Processing: Turn captured observations into more structured records using a locally running AI model.
🌱 Sticker Garden: Earn daily stickers for qualifying observations, build exploration streaks, and collect sticker artwork as you keep exploring.
✨ A Personal Exploration Record: Revisit your saved traces and build a growing record of the places, sights, and sounds you've encountered.

The small details matter. A photo captures what you saw. Audio captures what you heard. A location gives that moment a place on the map. Together, they help turn an ordinary walk into something worth remembering.

🎥 Demo

Watch TRACE in action:

Trace demo - Google Drive

drive.google.com

In the demo, I'll walk through the map, create an observation using multimedia input, show the local AI processing flow, and finish with Sticker Garden and its daily reward system.

💻 Code

GitHub repository: https://github.com/shiriei/TRACE

TRACE is built around the idea that useful AI experiences don't always need to live in the cloud. The project brings together a map-based interface, real-world data capture, local inference, and a reward system designed around exploration.

Check out the repository to explore the implementation and follow the project's development.

🛠️ How I Built It

One of the central parts of TRACE is its use of local AI through LM Studio, running a 4-billion-parameter model on my machine.

Instead of sending every observation to a hosted AI service, TRACE connects to the locally running model for its AI processing workflow.

That choice comes with a trade-off: local inference can take a little time, depending on the hardware and input. But it also makes local execution a core part of the experience rather than an afterthought.

The rest of the application brings together an interactive map, text/photo/audio observation capture, saved traces, and the Sticker Garden reward system.

I wanted these pieces to feel connected. The map gives observations a place, multimedia capture preserves different kinds of experiences, AI helps structure the captured information, and daily rewards give users a reason to keep exploring.

🔓 Why Does Open Innovation Matter?

AI shouldn't be limited to applications that can afford a hosted API or send every request to an external service.

Open-weight models and local inference make it possible to experiment with AI in a different way: run models on your own hardware, build around them, and understand the practical trade-offs for yourself.

For TRACE, this meant being able to integrate a local model directly into an exploration workflow. It also meant working within the constraints of local inference, including processing time and available hardware.

Open innovation makes experimentation more accessible. Developers can build on available models, adapt them to their ideas, and create experiences that don't depend entirely on a closed AI service.

For me, TRACE is one small experiment in that direction: using local AI not just to generate text, but to support an activity that happens away from the screen.

🌱 The Bigger Idea

Gamification can easily become another reason to keep staring at a screen. I wanted to use it differently.

The map gives you a reason to notice. The capture tools help you preserve what you find. The AI helps organize your observations. Sticker Garden rewards consistency.

The real reward, though, is the world you're paying attention to.

Go outside. Notice more. Leave a trace.

🏆 Prize Categories

Best Use of Gemma
Use Gemma, Google's open-weight model, in building your project: run it locally, fine-tune it, or serve it through Google Cloud or another provider.

Built for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

PLATEWISE

Isha Gautam — Mon, 05 Oct 2026 00:26:28 +0000

PlateWise — Your Plate. Your Rules.

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built PlateWise, a simple AI-powered personalized meal planner.

I originally built it for a friend who wanted an easier way to plan meals while keeping personal preferences and food allergies in mind. I wanted to make something that could take a few basic details about a person and turn them into a meal plan that actually fits them.

With PlateWise, users can enter their dietary preference, fitness goal, allergies, foods they don't like, number of meals they want per day, and optionally their daily calorie target.

The app then uses this information to generate a personalized meal plan.

One thing I really wanted to get right was allergies. Instead of completely trusting the AI's response, I added a separate backend allergy checker that checks the ingredients generated by the AI against the user's listed allergies before showing the meal plan.

The basic idea was:

Let AI generate. Let the backend verify.

Code

GitHub Repository:
https://github.com/shiriei/PLATEWISE

The project is built as a small full-stack application using React, FastAPI, SQLite, and Gemini.

How I Built It

The frontend is built with React, Vite, and TypeScript, while the backend uses Python and FastAPI. SQLite is used to store the user's preferences and profile information.

For the AI part, I used the Gemini API to generate the meal plans based on the information provided by the user.

I also built a simple rule-based allergy checker in the backend. After Gemini generates the meal plan, the backend checks the ingredients against the user's allergies before returning the result.

The basic flow is:

User Profile
↓
FastAPI
↓
Gemini
↓
Meal Plan
↓
Allergy Checker
↓
Final Meal Plan

I wanted to keep the project simple rather than adding a lot of unnecessary features. The main focus was to make something useful, easy to understand, and safe enough to handle one of the most important pieces of information in a meal planner: the user's allergies.