AtlasResponse

An AI disaster-response agent that helps emergency teams find unmet needs, coordinate limited resources, and replan instantly as roads, needs, and response coverage change.

Comment

Inspiration

In disaster response, perfect information often arrives too late. Especially in less developed countries.

Emergency teams must act while the operational picture is still incomplete. Damage assessments may be partial, roads may be blocked, facilities may be offline, and information from different agencies arrives at different times.

Waiting for every input to be fully verified can delay critical action. But moving quickly without understanding the quality of the evidence can send limited resources to the wrong place.

The real challenge is not choosing between speed and trust. It is building a system that can support both.

Most disaster platforms focus on situational awareness: where an event happened, where damage has been observed, and which facilities or roads are nearby. Those views are essential, but the operational question begins afterwards:

Given what is known right now, where should limited response capacity go next—and how should that plan change when conditions change?

I built AtlasResponse to turn the best available disaster evidence into a provisional, explainable, and continuously updatable response plan.

What it does

AtlasResponse turns fragmented disaster evidence into a defensible provisional response plan.

It combines a constrained AI coordination layer with deterministic prioritization, resource allocation, routing, and versioned replanning.

AtlasResponse does not wait for every dataset to become complete. Instead, it separates incoming information into three operational categories:

  • Actionable evidence that can support an immediate recommendation
  • Explicit assumptions that enable bounded planning under uncertainty
  • Decision-critical gaps that remain visible because they could materially change the plan

This allows emergency planners to move forward without confusing uncertainty with certainty.

1. Build the current operating picture

AtlasResponse combines earthquake records, satellite damage observations, population context, roads, facilities, and response information in one geospatial workspace.

Each input retains its source, reporting cutoff, and evidence type so an operator can see what is observed, modelled, historical, operator-supplied, simulated, or still unknown.

2. Identify where attention should go first

The system divides the affected area into decision zones and ranks them using factors such as:

  • Observed building damage
  • Modelled resident population
  • Proximity to mapped health facilities
  • Operational eligibility constraints
  • Available assessment capacity

The result is not simply a heatmap. Each priority score includes an inspectable factor record showing the inputs and contributions that produced it.

3. Generate a provisional candidate plan

AtlasResponse matches operator-supplied teams and capabilities to eligible priority zones.

The plan shows:

  • Which team is assigned to which zone
  • What task the team should perform
  • The modelled travel time
  • Which constraints were satisfied
  • Which access assumptions remain uncertain
  • Which priority zones remain unassigned

Unknown road conditions do not automatically stop the entire planning process. An operator can explicitly allow uncertain road edges with a configurable penalty, producing a usable provisional route while keeping the associated risk visible.

4. Replan when access changes

When a road-status update arrives, AtlasResponse identifies which routes and assignments depend on that road segment.

It creates a successor road-network snapshot, removes the affected connection, recomputes the dependent routes, and generates a new candidate plan without overwriting the original.

This allows planners to respond quickly to new field information while understanding exactly what changed.

5. Keep human authority at the commitment boundary

Analysis, prioritization, candidate planning, routing, and replanning can run without waiting for manual approval at every step.

Human approval is required only before a recommendation becomes an operational commitment.

The system prepares and explains the decision. The authorized operator decides whether to commit resources.

Evidence
   ↓
Automatic prioritization
   ↓
Automatic allocation and routing
   ↓
Automatic replanning after a field update
   ↓
Human review before operational commitment

Two incident modes

AtlasResponse demo demonstrates how the same system behaves at different levels of information readiness.

Western Colombia earthquake — active situation

The Colombia workspace uses a time-stamped situation snapshot assembled from official and public sources, including USGS, Servicio Geológico Colombiano, OCHA, Copernicus EMS, and OpenStreetMap.

AtlasResponse presents:

  • The reviewed earthquake event
  • Modelled shaking intensity
  • Reported aggregate impacts
  • Baseline roads and mapped structures
  • Available source coverage
  • The operational inputs that remain incomplete

The available snapshot can support rapid situation intelligence, evidence triage, and scenario preparation. However, it does not yet contain the municipality-level needs, operational resource inventory, facility capacity, and response coverage required for a defensible real-world allocation.

AtlasResponse therefore continues analysing and preparing the incident while clearly identifying which additional inputs would unlock operational planning.

Its limitation is specific to allocation—not to situational awareness or evidence preparation.

The system does not invent missing teams, facility capacity, beneficiary estimates, medical demand, or road conditions simply to make the dashboard appear complete.

2025 Myanmar earthquake — historical response replay

The Myanmar workspace demonstrates the complete operational loop using a frozen historical snapshot and an explicitly labelled rapid-assessment exercise.

It combines:

  • 1,555 preliminary UNOSAT damage observations
  • GHSL population context
  • HOT/OpenStreetMap roads and mapped health facilities
  • USGS earthquake data
  • MIMU coordination context
  • 169 deterministic priority zones
  • Three operator-supplied rapid-assessment teams

AtlasResponse ranks the affected zones, assigns the available teams, and generates modelled routes across the road network.

Because current passability is unknown, the exercise explicitly allows uncertain road edges with a penalty. The system can therefore produce a provisional plan immediately without presenting those roads as confirmed safe.

A simulated road closure is then introduced. AtlasResponse traces the affected dependencies and produces a successor plan in which three routes change while the original team-to-zone assignments remain stable.

The first plan remains available for comparison, and the updated recommendation is prepared for human review.

How I built it

Geospatial evidence pipeline

I designed a versioned evidence model that binds each external input to its:

  • Source
  • Retrieval time
  • Reporting cutoff
  • Provenance class
  • Spatial boundary
  • Content hash
  • Operational limitations

The pipeline distinguishes between:

  • Observed source data
  • Derived model outputs
  • Operator-supplied information
  • Scenario assumptions
  • Simulated updates
  • Unknown values

This classification happens before information reaches the planning layer. It allows AtlasResponse to use partial evidence without flattening every input into the same level of certainty.

At the product level, the central truth boundary is:

Observed ≠ Derived ≠ Operator-supplied

Priority model

For the Myanmar replay, I generated 169 deterministic analysis zones.

Each zone contains an inspectable factor record covering observed damage, population context, facility proximity, eligibility gates, and policy contributions.

The priority model supports rapid-assessment planning. It ranks where assessment attention should go first without turning modelled context into unsupported claims about verified humanitarian need.

Allocation and routing engine

I constructed a road-routing graph containing:

  • 13,282 nodes
  • 17,071 edges

The graph uses frozen OpenStreetMap topology and supports explicit routing policies for uncertain access.

The planning engine combines:

  • Priority scores
  • Resource capabilities
  • Task requirements
  • Capacity constraints
  • Network reachability
  • Access assumptions
  • Scenario penalties
  • Locks, reserves, and exclusions

It then uses deterministic bounded search to produce a reproducible candidate plan.

The same incident state, evidence, resources, constraints, and road-network version produce the same planning result.

Versioned replanning

Every candidate plan is bound to the exact incident snapshot, priority policy, resource scenario, and road-network version that produced it.

When access information changes, AtlasResponse creates a successor network snapshot and recomputes the dependent routes. The previous plan is preserved, and a structured diff records:

  • Assignment changes
  • Route changes
  • Reachability changes
  • Remaining unassigned demand
  • Objective changes
  • The reason the successor plan was created

This provides rapid replanning without losing the operational history.

AI coordination layer

I built a read-only AI coordination layer that can inspect the current Situation, Coordination, and Plan views and assemble an operational briefing from server-authored claims.

The AI layer helps an operator understand:

  • What changed
  • Which gaps matter
  • Which recommendations are supported
  • Which assumptions affect the plan
  • What requires human review next

The AI cannot approve plans, dispatch resources, or silently create operational facts.

I deliberately kept decision-critical computation outside the generative layer. Priority scoring, allocation, routing, and replanning remain deterministic and reproducible; the AI layer focuses on synthesis and explanation.

Application stack

I built the operational interface using:

  • React
  • Vite
  • Mapbox GL JS
  • Interactive GeoJSON layers

Supabase and PostgreSQL provide persisted incident records, source registries, resource scenarios, immutable plan versions, access roles, and private operator state.

The public application is deployed on Vercel and connects to a dedicated hosted backend.

Verifiable plan commitments

For approved plan versions, I implemented a tamper-evident commitment prototype through ResponseCommitmentLedger.

The role-gated, append-only contract binds the incident, network, scenario, plan, review, and predecessor hashes into a verifiable record. This makes it possible to verify that an approved plan has not been silently changed without placing sensitive operational data on-chain.

The contract targets Base Sepolia and currently passes 9/9 unit tests.

Testnet deployment is pending, so the current implementation is a tested commitment prototype rather than a claim of live on-chain operation.

Challenges I ran into

Acting before the information is complete

The central challenge was designing a system that could remain useful under uncertainty.

A strict “only act on fully verified information” rule would make the system too slow for crisis response. Treating every available signal as equally reliable would make it unsafe.

I designed AtlasResponse to generate provisional recommendations from the best available evidence while exposing the assumptions that could change them.

Turning data gaps into operational information

A missing road-status feed should not look like an open road. A mapped hospital should not automatically look operational. Missing response records should not imply that no aid exists.

I had to make these gaps visible without allowing them to paralyse the entire workflow.

AtlasResponse can continue where bounded assumptions are acceptable and abstain where a missing input would invalidate the recommendation itself.

Replanning without losing the past

During a crisis, plans can change rapidly. Simply replacing the old output would make it impossible to explain why a route or assignment changed.

I built immutable plan versions, successor network snapshots, dependency tracking, and structured diffs so the system could move quickly while preserving accountability.

Presenting complex evidence clearly

The underlying workflow contains satellite observations, population models, priority factors, resources, road networks, scenario assumptions, and plan versions.

I separated the product into Situation, Priorities, Candidate Plan, Live Operations, Replan, and Audit views so operators can move from understanding an incident to reviewing the next action without needing to understand the underlying database structure.

Building the system as a solo developer

As a solo builder, I worked across product positioning, geospatial processing, database architecture, deterministic planning, routing, frontend interaction, deployment, testing, and the trust model.

The hardest scope decision was not deciding what else to add. It was deciding which claims the available evidence and implementation could genuinely support—and refusing to make the interface appear more operationally complete than it was.

Accomplishments that I am proud of

  • Built a complete situation → priority → allocation → routing → update → replan → commitment workflow
  • Designed the system to act on incomplete information through explicit, bounded assumptions
  • Used real geospatial sources instead of placeholder disaster data
  • Generated 169 deterministic priority zones
  • Constructed a 13,282-node and 17,071-edge routing graph
  • Produced scenario-aware routes with explicit penalties for uncertain access
  • Preserved every candidate plan as an immutable, version-bound record
  • Created a structured before-and-after replan diff
  • Recomputed three affected routes while preserving the original team assignments
  • Separated active situation intelligence from historical response simulation
  • Placed human approval at the operational commitment boundary instead of throughout the analytical workflow
  • Implemented a role-gated, append-only plan commitment contract with 9/9 unit tests passing; Base Sepolia deployment is pending
  • Passed 75/75 API verification checks
  • Passed 619/619 database verification checks
  • Passed frontend type checking, linting, unit testing, production build, and browser-flow verification

What I learned

Speed and trust are not opposites.

A trustworthy disaster-response system should not wait for certainty that may never arrive. It should show which actions are supported now, which depend on explicit assumptions, and which would be unsafe to recommend.

I also learned that human-in-the-loop design depends on where the human is placed.

Requiring approval for every analytical step creates delay. Removing human authority entirely creates unacceptable risk. AtlasResponse automates evidence processing, prioritization, planning, routing, and replanning, then asks for human authorization only when a recommendation is ready to become a real operational commitment.

I learned that provenance is not merely metadata. It directly changes what a system should be allowed to recommend. The distinction between observed, derived, assumed, simulated, and unknown information must be visible throughout the planning workflow.

Finally, I learned that a plan is only useful if it can change. During a crisis, the system must absorb new information, identify what it affects, and produce an updated recommendation without losing the reasoning behind the original.

What's next for AtlasResponse

Next, I want to connect AtlasResponse to:

  • Authenticated partner resource inventories
  • Geolocated 3W response-activity feeds
  • Live road-status observations
  • Facility-level operating capacity
  • Private field reports and supporting artifacts
  • Automated incident and access-change alerts
  • Shared multi-agency planning workflows
  • Offline and low-connectivity access for field teams

I also plan to:

  • Expand the system beyond earthquakes
  • Turn historical incident replays into reusable preparedness and training exercises
  • Evaluate the prioritization and planning rules with humanitarian practitioners
  • Improve uncertainty and confidence communication
  • Deploy and verify the commitment contract on Base Sepolia after further review

The long-term goal is to make AtlasResponse a reusable coordination layer across incidents, agencies, and regions—helping response teams act earlier, adapt plans as conditions change, and commit limited resources with clear evidence, traceable assumptions, and human operational authority.

Built With

Share this project:

Updates

Submission history