Inspiration
In the terrifying aftermath of a massive earthquake, the most agonizing tragedy isn't just the crumbled buildings, it's the helpless silence. Thousands of people remain trapped beneath rubble while calls flood emergency centers, leaving first responders blind to who needs help first and how to reach them before time runs out. We build this platform out of a simple belief: that technology should stand between life and loss. By grounding AI in real Japanese seismic physics rather than guesswork, we can cut through the noise and chaos of a crisis and guide rescue teams directly to trapped victims, ensuring that when seconds mean everything, no one if left waiting in the dark.
What it does
KYU-BOT generates a high fidelity earthquake around Shinjuku, Tokyo using real 3D city data, soil amplification maps, and Japanese seismic engineering formulas. It calculates the exact hidden truth: which builds collapse, which roads are blocked by debris, and where people are trapped or hurt.
Then, it streams a chaotic feed of around 120 calls, social media posts, and eye witness texts. These reports include real world noise such as duplicate calls, exaggerated injury counts, wrong locations, and false rumors.
Next, a team of specialized AI agents process the incoming report stream:
- Medical Agent: Filters injury reports into a prioritized triage list showing trapped / critical victims per location.
- Verification & Assessment Agents: Merge duplicate reports and verify claims against existing evidence.
- Routing & Resource Agents: Find eligible rescue teams and plot routes around blocked streets using road graphs.
- Planning Agent: Generates actionable rescue plans.
Later, the proposed rescue plans, responder locations, and route updates are displayed on a 3D MapLibre interface for a human operator to review and approve. If a road collapses mid run, the AI automatically detects the blockage, reroutes the responders, and explains why.
Finally, at the end of the simulation, the system compares what the AI agents believed was happening against the hidden physical reality stored in the backend. It outputs a scorecard rating how accurately the AI found trapped victims, filtered rumors, and routed teams through open roads.
How we built it
Frontend:
- React + TypeScript for the dashboard, built and served with Vite.
- MapLibre GL for the 3D map of Shinjuku: extruded buildings, road layers and report dots.
- OpenFreeMap / OpenStreetMap for the background map tiles.
- lucide-react for icons.
Backend:
- FastAPI (Python), the API that the simulator, website and agents all go through. It checks input with Pydantic and runs on uvicorn.
- psycopg connects it to the database.
Databases:
- Neon (Postgres + PostGIS): the static map: buildings, roads, facilities everything agents may see: runs, reports, incidents, road restrictions, units, decisions PostGIS handles the locations and geometry
- Databricks: the hidden truth (real damage, people, the answer key) and the scorecards. Agents have no access to it.
Simulator (Python):
- Shapely for geometry, like which roads are under a collapsed building's debris.
- NetworkX for the road graph and routing (A* routes, nearest units).
- SciPy for matching units to incidents.
- OSMnx to build the road graph from OpenStreetMap (run once, on a laptop).
- Its own small FastAPI service on port 8100, which the map calls for Generate and the live clock.
AI:
- Gemini (through the google-genai SDK): writes the report wording, which is what we built planned for the agents
- The agents may run on an open model (Qwen via Hugging Face) instead.
- Whisper (Hugging Face) is planned for turning emergency-call audio into text.
Data sources:
- Project PLATEAU (Japan's 3D city model) for buildings.
- OpenStreetMap for roads.
- J-SHIS for soil.
- Published earthquake research for the damage formulas.
Tooling:
- pytest for tests.
- dev.sh (Mac/Linux) and dev.ps1 (Windows) start everything.
- Git + GitHub with pull requests.
Challenges we ran into
Lots of Merge Conflicts, Unfamiliar with Neon and had a hard time assigning permission and roles since each agents had a different role, the simulation needed access to the database directly and that made it difficult to learn, getting everything merged into the 3D rendering simulation and getting everything to work simultaneously without having to click a button.
Accomplishments that we're proud of
We are proud of the fact that we were able to create and use a very complex database schema on a new database. Furthermore, we were also able to successfully fuse real 3D building data from PLATEAU, soil amplification models and road networks into one unified map.
What we learned
We learnt a lot about how to use a Databricks and Neon, and were able to delve into the world of 3D modeling and simulations. We also learnt how to orchestrate multiple AI Agents. We were also able to learn a lot about how to create systems and pipelines to ensure that we have efficient workflows.
What's next for KYU-BOT
While Japan has an incredible national disaster communication infrastructure, a catastrophic earthquake can still fracture internet connectivity. That's why our natural next step for KYU-BOT is local, edge native deployment. This would allow the entire multi agent pipeline to run entirely offline on local hardware, ingesting radio and mesh network traffic to coordinate life saving rescues even when the grid goes completely dark
Built With
- databricks
- fastapi
- gemini
- maplibre
- neon
- networkx
- openstreetmap
- plateau
- postgis
- postgresql
- react-native
Log in or sign up for Devpost to join the conversation.