AFTERSHOCK

Inspiration

On June 24, 2026, Venezuela was hit by two major earthquakes just 39 seconds apart. Within hours, organizations like Copernicus Emergency Management Service and the USGS had already published satellite damage assessments and seismic data. That got us thinking: we already have systems that can identify damaged buildings, but what happens after that?

The hardest part of disaster response isn't always understanding what was damaged, it's deciding what to do next. Medical teams, heavy equipment operators, and coordinators all look at the same situation differently. We wanted to explore how AI could help visualize those different perspectives instead of assuming there's only one "correct" priority. Rather than building another damage detection model, we focused on the decision layer that comes afterward.

What it does

Aftershock is a spatial AI decision-support prototype built on real disaster data from the June 2026 Venezuela earthquakes. Using Copernicus EMSR884 building assessments and USGS ShakeMap data, our system generates different priority rankings for different responder roles instead of producing a single universal answer.

Medical Agent prioritizes buildings based on structural damage severity to help guide search-and-rescue efforts.
Machinery Agent combines damage severity with spatial clustering to determine where limited heavy equipment can have the greatest impact.
Coordinator Agent analyzes both perspectives and recommends how the two teams should coordinate when their priorities differ.

The result is an interactive spatial dashboard where users can switch between responder roles and immediately see how priorities shift depending on the objective, along with AI-generated explanations for every recommendation.

How we built it

We built Aftershock using real humanitarian datasets rather than synthetic examples. We began by parsing Copernicus EMSR884 building assessments for Caraballeda, Venezuela, then combined them with USGS ShakeMap intensity data and geospatial building coordinates to generate responder-specific priority scores.

For our ranking system, the Medical Agent uses structural damage severity, while the Machinery Agent applies severity together with haversine-distance clustering to prioritize dense areas where heavy equipment can be used most efficiently. When those two rankings disagree, a Coordinator Agent generates a recommendation on how both teams should sequence their response. To make the rankings easier to understand, we generated natural-language explanations using OpenAI's GPT-4o mini.

The application was built with React, TypeScript, MapLibre GL, and WebSpatial for PICO. We used real satellite imagery, terrain elevation, and an interactive 3D map to let users explore the disaster area and compare responder perspectives in real time.

Challenges we ran into

Like most hackathon projects, our final solution looked very different from our original plan. We initially wanted heavy equipment routing to account for blocked roads using OpenStreetMap transportation data. After integrating the dataset, we discovered it didn't contain reliable road status information, so we pivoted to a clustering-based scoring system instead. In the end, this actually produced more realistic recommendations for equipment deployment.

Another major challenge was our visualization pipeline. Our first implementation used React Three Fiber, but we repeatedly ran into WebGL conflicts with the WebSpatial SDK. After several debugging sessions, we decided to rebuild the map using MapLibre GL. Although it meant scrapping a significant amount of work, the new approach gave us a much more stable 3D experience with terrain, satellite imagery, and smoother interaction.

Finally, we had to make difficult scope decisions. Features like live cross-role collaboration, volunteer responders, and aftershock simulation were all part of our original vision, but we chose to focus on building one polished end-to-end workflow rather than several incomplete ones.

Accomplishments that we're proud of

We're proud that Aftershock is built around a real humanitarian event instead of a fictional disaster. Every building, damage assessment, and shaking intensity shown in our application comes from publicly available emergency response datasets.

More importantly, we moved beyond simply visualizing disaster damage. Aftershock demonstrates how multiple AI agents can reason from different operational perspectives and how another AI agent can help reconcile those competing priorities. Watching those perspectives disagree and why became one of the most compelling parts of the project. Our team successfully integrated geospatial data processing, AI-generated explanations, multiple ranking algorithms, and an interactive spatial interface into a working prototype within 24 hours.

What we learned

One of our biggest takeaways was that disaster response isn't a single optimization problem. As we built our scoring system, we realized different responders naturally prioritize different things. Search-and-rescue teams focus on structural severity, while heavy equipment operators must think about where limited machinery can make the greatest overall impact. We learned how much high-quality humanitarian data is already publicly available. Copernicus, USGS, and OpenStreetMap all released valuable datasets shortly after the earthquake.

What's next for AfterShock

Aftershock was built as a proof of concept, but we see plenty of opportunities to expand it. Our next goal is to support additional disaster events around the world so the platform can adapt to different emergency scenarios. We'd also like to incorporate real-time infrastructure data such as road closures, weather conditions, and accessibility constraints to improve responder recommendations. We'd love to validate our approach with emergency management professionals and humanitarian organizations to better understand how spatial AI systems like Aftershock could support the people making critical decisions during disaster response.