Live command: Claude coordinates engine assignments and evacuation orders in a labelled simulated drill.
Wildfire spread on Berkeley Hills terrain. Simulated fire and synthetic homes, with observed weather inputs.
Simulation Studio: multiple simulated fires on LANDFIRE fuels and terrain in the Berkeley Hills.
Camp Fire historical replay, with reconstructed events and modelled fire and traffic labelled separately.
The audit log preserves Claude’s simulated dispatch decisions, explanations and resulting actions.
Engines deploy hoses near the fire while crews build control lines in a simulated Live Command exercise.
Claude coordinates flank assignments as simulated engines work around the fire and containment progresses.
100% modelled containment: the fire is held while crews complete mop-up. Containment is distinct from extinguishment.
Fire resolved: the simulator confirms the fire is out, logs the outcome, and returns engines to service.
Panoramic Hill drill: fire resolved at T+17 min; Claude issued an all-clear and 32 evacuated households returned home.
Mobile exercise: Claude’s simulated evacuation order reaches the iPhone with “Leave now” guidance and a route to CA 13.
Mobile exercise: route guidance via Sports Lane to CA 13, with the destination and estimated travel time shown on the map.
Mobile field reporting: select a hazard, pin its location and add context. This smoke report is explicitly labelled as a practice exercise.

Inspiration

I have many family friends in Los Angeles, so the LA fires felt personal. They made me think about the people behind each evacuation decision, and how much information responders have to combine while conditions keep changing.

Then, on October 20, a brush fire broke out near Panoramic Hill in Berkeley. Crews brought it under control, but it brought the same question closer to home: how can a fire department coordinate its response when the fire, traffic and available resources are all changing together?

That became CrisisTwin. We wanted to build an environment where responders could rehearse those decisions and see their consequences. Our prototype starts with a simulator that connects wildfire spread, evacuation traffic and an AI dispatcher in one interactive world.

What it does

CrisisTwin is an interactive wildfire simulator for rehearsing dispatch and evacuation decisions.

Start a fire, change the wind or close a road, then watch how fire spread, evacuation traffic and responder access interact. Claude monitors the simulated situation and assigns engines or stages evacuation waves. A decision timeline shows what it did and why.

Users choose a landscape, set wind and fuel moisture, place ignitions and play the scenario forward on a map or in a 3D diorama. The fire model uses real LANDFIRE fuels and terrain, with crown-fire modelling where canopy data is available.

Simulation Studio combines multiple fires, synthetic households, road closures and firefighting resources. Closing a road changes which routes remain available and how traffic moves. Ground crews and aircraft introduce further decisions about access, arrival and whether a modelled control line holds. For fire attack, Claude chooses among tactics whose outcomes the simulator has already calculated.

Historical replay supports exploring past incidents. A SwiftUI companion app adds labelled drill guidance, field reports and check-ins; resident and voice workflows still need end-to-end verification on devices.

CrisisTwin is an experimental planning prototype. Observed source data, user assumptions, synthetic households and simulated outcomes are labelled separately. Its results are not operational evacuation instructions.

How we built it

The frontend uses React and TypeScript, with three.js for the 3D diorama and MapLibre for map views. We keep simulation calculations separate from rendering and AI integration, and run the Studio fire solver in a Web Worker so the interface stays responsive.

The surface-fire model implements Rothermel spread using fuels, terrain and environmental inputs. Canopy data supports crown-fire modelling. Ember spotting and structure-to-structure spread use coarser approximations, presented as separate layers. Evacuation and resource models calculate traffic, road access and responder movement.

A Django REST backend connects the workspace to external data providers. MongoDB Atlas stores incident packages, cached landscape data and dispatch-run journals.

Claude receives structured simulation observations and a constrained set of actions. The server validates its proposals against the scenario, while numerical code determines routes, spread and traffic. This lets us inspect the model’s decisions separately from their simulated consequences.

The iOS companion uses SwiftUI. Its optional voice workflow uses Cartesia for speech recognition and synthesis, with language-model processing on the server. Provider API keys remain server-side.

Challenges we ran into

The hardest engineering problem was keeping several changing systems consistent. A road closure affects both evacuating households and approaching engines. An engine assignment only makes sense if that engine can reach its destination. Fire, traffic and dispatch therefore have to operate on a consistent simulation state.

We addressed this by making road access and numerical simulation constrain the actions available to the dispatcher. For fire attack, we give Claude precomputed tactical options instead of asking it to invent outcomes.

Another challenge was communicating uncertainty. A scene can combine real terrain, synthetic homes and assumed weather. We had to make those distinctions visible while keeping the 3D view understandable during a short demo.

Accomplishments that we're proud of

We connected fire behaviour, evacuation traffic and responder decisions in one interactive prototype. A user can close a road, watch the consequences and inspect how the AI dispatcher responds.

We also built a reviewable decision process. Claude’s actions and explanations appear alongside simulated outcomes, and run journals preserve decisions for later inspection.

The 3D diorama brings the problem together visually: fire, roads, households and responders share the same scene, making their interactions easier to follow.

What we learned

We learned that building an AI dispatcher requires building an environment it can reason within: explicit state, constrained actions, numerical models and visible feedback. An assignment becomes meaningful when the system can determine whether it is possible and show what follows.

We also learned that visual clarity is part of model integrity. A convincing simulation needs equally clear explanations of which inputs are observed, which are assumed and which outcomes are computed.

What's next for CrisisTwin

Our next priority is validation with domain experts and historical incidents. We want to compare modelled fire and evacuation behaviour with real evidence, measure sensitivity to assumptions and identify where the prototype breaks down.

We also want to improve household behaviour and suppression modelling, make runs easier to reproduce and compare, and finish device verification for resident and voice workflows.

Our first product target is an exercise and after-action review tool for a single department and its local area. Supporting live wildfire response is a longer-term ambition that would require validation and development with the responsible agencies.

Claude for Public Benefit

Wildfire response involves decisions that affect whole communities. Our goal is to make those decisions easier to rehearse, inspect and discuss.

Claude provides a readable decision layer: it reviews simulated conditions, proposes evacuation waves and engine assignments, and explains its reasoning. Users can examine those choices alongside their simulated consequences.

By preserving that connection between observations, decisions and outcomes, CrisisTwin gives people a way to question an AI response and learn from it during an exercise.