Aftershock

Inspiration

After seeing the impact of recent earthquakes in Venezuela, we started thinking about a problem that is easy to overlook in disaster response: rescuers often do not suffer from a lack of information — they suffer from too much fragmented information.

A radio call may report trapped civilians. A social media post may describe the same building differently. A drone may later confirm that people are actually there. Meanwhile, roads can become blocked and rescue teams are already moving.

The difficult part is turning all of that into one shared, continuously updated understanding of the disaster.

We built Aftershock to explore how AI can help emergency teams do exactly that — without turning life-or-death decisions over to a black-box model.

What it does

Aftershock is an AI-assisted coordination system for earthquake search and rescue.

It combines reports from radio, social media, drones, field observations, and disaster data into a shared operational belief state: a structured representation of what the system currently knows, how confident it is, where incidents are located, and what rescue resources are doing.

From that shared state, Aftershock coordinates two connected layers:

Search decides where more information would be valuable. Uncertain but potentially high-impact incidents can be sent to drones for verification.
Save decides how rescue resources should respond to the incidents that are currently supported by the available evidence.

Both layers operate on the same live operational state, rather than maintaining separate versions of reality.

That means new information immediately affects the rest of the system.

A victim report can create or strengthen an incident. A drone observation can confirm or contradict it. A rescue team can be dispatched to a worksite. If a road becomes blocked while that team is moving, Aftershock updates the road network and automatically finds a new route to the same objective.

We intentionally place a boundary around automation: route-level changes can happen automatically, but changing a rescue team's mission to a different objective requires explicit human approval.

How we built it

We designed Aftershock as a pipeline of small, inspectable components instead of one large AI agent.

1. From messy reports to structured evidence

Incoming reports can be informal, incomplete, or inconsistent.

We use the OpenAI Responses API with Structured Outputs to transform this information into validated StructuredObservation objects.

The model is responsible for interpreting human language, but its authority is deliberately limited. It cannot invent canonical site IDs, coordinates, rescue priorities, or team assignments.

Those decisions belong to deterministic parts of the system.

2. A shared operational belief state

Every accepted observation updates a canonical OperationalBeliefState.

This state tracks information such as:

known sites and incidents
supporting and conflicting evidence
current worksites
rescue resources
drone observations
road conditions
team movement
current assignments

Search and Save both read and update this same state, so a change discovered by one part of the system becomes immediately visible to the other.

3. Evidence fusion

Multiple reports may refer to the same real-world incident.

Aftershock resolves reports to known geographic sites and combines related observations instead of treating each report as an independent emergency.

The system preserves provenance and uncertainty so responders can distinguish between something that has merely been reported and something that has been independently verified.

4. Search

The Search layer identifies places where additional information could meaningfully change the operational picture.

For example, if an uncertain report suggests trapped victims at a high-impact location, a drone can be tasked to inspect it.

The resulting observation is fed back into the same belief state, where it can strengthen, weaken, or resolve the incident.

5. Save

Once evidence supports an actionable worksite, the Save layer evaluates rescue priorities and available teams.

Instead of asking an LLM which victim to rescue, we use explicit scoring functions for concepts such as rescue priority, assignment utility, and reassignment gain.

This makes the system's behavior reproducible and easier to inspect.

6. Real routing and live road updates

Our demo uses real OpenStreetMap building and road data from Caraballeda, Venezuela.

Rescue teams travel through a connected road graph using shortest-path routing based on their current position.

Roads can dynamically move between states such as OPEN, LIMITED, and BLOCKED.

If a road on an active rescue route becomes blocked, Aftershock recomputes a valid path from the team's live position and reroutes the team toward the same worksite.

If reaching a different victim would require changing the team's objective, the system stops and asks for human approval instead.

Challenges we ran into

One of the hardest design decisions was determining where AI should stop.

It would have been easy to build one large agent that reads reports, decides which victims are important, assigns teams, and generates routes.

It would also have been extremely difficult to trust.

We instead separated the system into distinct stages:

extraction → location resolution → evidence fusion → operational state → search prioritization → rescue prioritization → routing → execution

This made the architecture more complicated, but it also made every important transition observable.

Another major challenge was getting Search and Save to operate as one system.

Earlier designs could easily create two separate "belief universes": one used to decide what drones should investigate and another used to decide where rescue teams should go.

We replaced that with a single canonical operational state. Now a Search observation can directly influence Save, and a road update can affect an already executing rescue assignment without reconstructing the scenario.

Real map data introduced another set of problems. Buildings do not always have obvious road-access points, road graphs contain one-way streets and disconnected segments, and blocking a single edge can unexpectedly make a destination unreachable.

We had to build and test our scenario around these real geographic constraints rather than assuming a perfect grid.

Accomplishments that we're proud of

The part we are most proud of is that Aftershock now works as a connected operational loop rather than a collection of independent demos.

In our demo, the system can:

ingest an uncertain human report
convert it into structured evidence
resolve it to a real location
update a shared operational belief state
prioritize additional Search when evidence is incomplete
incorporate drone verification
create an actionable rescue worksite
assign a rescue team
route that team through a real road network
update its position as it moves
respond to a newly blocked road
automatically reroute toward the same objective
require human approval before changing the team's rescue mission

We are also proud of the division of responsibility inside the system.

AI interprets messy human information.
Deterministic systems maintain state and calculate operational actions.
Humans retain authority over major rescue decisions.

What we learned

The biggest thing we learned is that disaster response is not simply an optimization problem.

Before asking, "Which rescue team should go where?", the system first has to answer:

What do we actually know?

A social media post is not automatically a victim. Two reports are not automatically two incidents. A possible location is not automatically a confirmed worksite.

Useful coordination therefore requires uncertainty, provenance, geography, and operational state to survive all the way through the system.

We also learned that the distinction between Search and Save is important.

Sometimes the highest-value action is not immediately sending a rescue team. It is gathering one more piece of information that prevents that team from being sent to the wrong location.

Finally, we learned that human-in-the-loop design is more meaningful when it is built into the architecture rather than added as a confirmation button at the end.

In Aftershock, we distinguish between low-level execution changes and high-level mission changes. The system can respond quickly to a blocked road, but it cannot silently decide that a rescue team should abandon one victim for another.

What's next for Aftershock

Aftershock is currently a hackathon-scale prototype built around a deterministic earthquake scenario, but the architecture is designed to extend beyond that demo.

Next, we would like to add:

richer drone imagery and computer-vision observations
additional real-time disaster and infrastructure feeds
stronger temporal and multi-source evidence fusion
coordination across larger fleets of drones and rescue teams
multi-team scheduling and resource constraints
changing road capacity and infrastructure damage
responder-facing explanations for why priorities changed
replay against historical earthquake scenarios
evaluation with emergency-management and disaster-response experts

Longer term, we see Aftershock not as an autonomous disaster commander, but as a shared decision-support layer between humans, sensors, AI systems, and rescue resources.

In a disaster, every team sees only part of the situation.

Aftershock is designed to help them see the same picture.