AidScaler · DISASTER RESPONSE
Turn scattered signals into coordinated help. Make more time to protect lives.
THE PROBLEM · DOCUMENTED EVENTS
Maiti Nepal's founder described seeking approval from three government ministries for donated medicine and mats. VOA reported repeated trips for clearance signatures as relief supplies piled up at the airport.
Read the report · VOA · 2 May 2015
Rescuers raced through the critical first 72 hours as damaged roads hindered access to communities. The search continued beyond that window: urgency was a reason to move faster, not to stop helping.
Read the report · Euronews / AP · 4 Jan 2024
Pam cut communications to outer islands. To build a clearer picture, humanitarian volunteers pieced together social posts, news and geotagged photos—helping responders see where to investigate and send aid.
Read the report · The New Humanitarian · 14 Apr 2015Historical reporting, with photographs from each event. AidScaler was not used in these responses.
MEET AidScaler · YOUR RESPONSE PLATFORM
An AI-native disaster response platform for NGOs, emergency services and public response teams. Gemini connects scattered public information with your team's resources—so you can see what is needed and coordinate how to help.
300 people at a shelter.
A request scattered across several sources.
01 — WHEN A DISASTER SPEAKS IN FRAGMENTS
A post. A voice note. A radio bulletin. Gemini connects the clues while the situation changes.
A community’s voice.
The start of a response.
02 — ONE DISCOVERY INSIDE A LARGER EMERGENCY
It is 10:00. A shelter requests 600 litres by noon.
No organization has the full answer. A clue in another operation changes what is possible.
That was one discovery.
Now imagine a hundred, in parallel.
THE AMBITION · A REGION-WIDE RESPONSE
An illustration of many cases across a response network. Measured performance appears in section 04.
03 — A RESPONSE THAT CAN ADAPT
Explore one change. See what needs attention—and what can safely keep moving.
04 — MEASURED IMPACT
Earlier authorization. Earlier delivery. Less work to coordinate it all.
Average wait across 8 food needs. Both methods delivered all 164 required portions.
Conventional 51.16 min→AidScaler 17.59 min
05 — NOT EVERY NEED MAKES NOISE
Gemini looks for missing coverage and conflicting accounts. Priority comes from need, not popularity.
“No contact
with Bajo Monte
since 09:10.”
Reports stop in an area that was previously active. Gemini cross-checks connectivity notices and nearby field reports.
“The school”, “Los Sauces” and “the building beside the sports field” may describe the same place. Gemini connects the references with field reports.
One organization has supplies, another has transport, a third knows the local access conditions. That information lives in separate documents, voice notes and inventories.
ILLUSTRATIVE USE CASES · explore measured response results in section 04.
06 — A PUBLIC PORTAL THAT BUILDS TRUST
Support the response from anywhere. See what is needed, what is moving and what has arrived.
Real progress, made understandable.
Gemini drafts the update. The organization reviews and publishes.
Trust grows when
progress can be checked.
THE BIGGER PICTURE
Needs surface across social posts, videos and news. Each team sees only part of the situation.
One organization already gets the full intelligence layer. Approved public and social sources feed AidScaler through connectors, alongside its internal tools and local reports. Gemini relates posts, videos, news and operational data; groups duplicates; flags contradictions; and investigates needs and response options. A team does not have to enter every signal by hand. Source access depends on available APIs, permissions and agreements.
The network adds shared possibilities, not just more dots on a map. One team may detect a need, another may have the local knowledge to verify it, and another may hold the missing capacity. Connected instances exchange the evidence, availability and commitments they are allowed to share. Gemini can investigate combinations that no organization could see on its own, without counting the same resource twice.
Each organization stays in control. People authorize their contributions. If an offer is withdrawn or new evidence changes a need, affected teams receive the update and can reconsider the joint response. More connections do not guarantee more impact; the simulator must test whether useful cooperation improves outcomes with the same total resources. This map illustrates the intended capability, not a validated result.
07 — DESIGNED FOR GOOGLE CLOUD
Built around the demands of an emergency: surging reports, changing priorities and teams working together.
PROPOSED ARCHITECTURE · NOT YET DEPLOYEDInterprets signals and investigates options.
Team sign-in and web experiences.
Agents and connectors that scale with demand.
Share changes. Preserve commitments.
Firebase Authentication for team sign-in; organization permissions enforced in services. Firebase Hosting for the operational interface and public portal.
Cloud Run for services with configurable scaling and concurrency. Pub/Sub for events. Cloud SQL for PostgreSQL for persistent state. Cloud Storage for evidence and documents.
Retries, quotas, reservations, access controls and change reconciliation still need implementation. Scale must be tested alongside latency and cost.
FOR YOUR ORGANIZATION’S TECHNICAL TEAM
Deploy the services, connect approved sources and choose what to share. Start with one organization. Connect when you are ready.
THE FUTURE WE WANT TO BUILD
Find help that was hidden in the noise.
Make more time to protect lives.
An AI-native operations platform for NGOs, emergency services and public response teams. It brings scattered reports, resources and decisions into one workspace during floods, earthquakes and other emergencies. Each organization keeps control of its resources and can connect with other teams.
Through a public portal: see current needs, support the responsible organization and follow collective progress. Contributions would support a shared response fund, rather than reserve a specific item. Organizations review what is published and protect sensitive information. This concept site does not accept donations.
The people responsible for the operation. Gemini investigates options and presents evidence, conditions and open questions. AidScaler would record who approved each commitment and what they knew at the time. A proposal does not move resources without authorization.
It can connect clues that were never expressed as an offer of help. “We are driving back empty” might reveal transport capacity. Gemini would investigate the schedule, load, access and existing commitments before presenting an option. Gemini interprets and investigates. Tools calculate constraints. People authorize the response.
They handle an important part of it: quantities, reservations, known constraints and routing. We want to test whether Gemini can discover useful relationships in unfamiliar, messy information and choose what to verify next. We will compare rules and planning, Gemini extraction with planning, and Gemini investigation with the same planning tools. Section 04 shows the measured comparison of the complete AidScaler workflow against the conventional method.
Keep the source, date and validity of each claim. Group reposts instead of counting them as independent witnesses. Separate a hypothesis from a confirmation. Flag an inconsistency without declaring it false. A community with no posts still needs attention. Silence does not prove safety.
AidScaler is designed to work alongside the systems response teams already use. Logistics sources could provide access conditions; internal tools could provide stock and commitments. Gemini would connect that context with scattered reports and other organizations.
Connectors are planned, not implemented. Each depends on available APIs, permissions and data agreements. No partnership is implied.
Inputs could include continuous streams from approved social and public sources: posts, videos, news and community updates, alongside field reports, documents, inventories and access restrictions. Connected sources would feed the platform automatically; manual reports are another input, not a prerequisite for every signal. Outputs could include evidence-backed incidents, proposals, changes and approved commitments. Connectors may be read-only. Writes must respect permissions, prevent duplicates and leave an audit trail. Another organization only exposes what it has agreed to share.
Yes. One instance helps a team interpret its sources, discover options and prepare decisions. Connected organizations can combine complementary capabilities to make a response possible that none could deliver alone. Each retains control of its data and commitments. We will test this with the same total resources, measuring cooperation separately from Gemini.
The platform has been built and tested with a working disaster-response simulator. In the recorded comparison, AidScaler reduced the average wait to authorize help by 30.49%, the average wait for sufficient aid by 20.59%, and recorded human workload by 93.48%. Both approaches fully covered 24 of 24 needs.
The interactive stories on this page illustrate the product experience. Section 04 presents the measured results.
On 13 October 2026, we compared a conventional workflow with AidScaler in two worlds using the same seed, resources, permissions and physical rules. Each had 24 needs: eight for water, eight for food and eight for blankets.
The conventional workflow models people reading, checking, deciding and relaying instructions, with explicit staffing and task durations. AidScaler processes the available information and coordinates its response within the same physical environment.
Every need has a recorded timeline: appearance, authorization, pickup, departure, arrival and receipt. Response times are averaged across all 24 needs; staff time is summed across the recorded tasks. Percentage reductions compare AidScaler directly with the conventional workflow.
Information takes time to arrive. The world separates what happens from what teams can observe. Public posts, reposts, background noise, delayed formal reports and human processing queues create a changing information picture.
Resources have physical constraints. Stock is finite. Vehicles must become available, receive instructions, travel to pickup, load, follow roads and unload. The engine supports traffic queues, road restrictions, fuel, connectivity loss and communication retries.
Help counts when it is received. Authorizing a shipment, reaching a destination and delivering the required quantity are separate events. The recorded comparison follows those events through to sufficient receipt. A shared seed and versioned configuration make comparisons repeatable.
Gemma 4 31B, via OpenRouter, powered this recorded AidScaler run. The charts therefore compare “Conventional” with “AidScaler”. Gemini is the model featured in the product vision and Google Cloud architecture shown elsewhere on this page.
The model, timestamps, resource quantities and event traces are recorded alongside the results, so each metric can be traced back to its source.
8.62 minutes less before authorization means the response can move beyond preparation sooner. 9.12 minutes less until sufficient aid is received means a shorter average wait at the affected location, including pickup, travel and unloading.
For the eight food needs, the average wait fell by 33.58 minutes. Faster coordination creates more time to protect people—the purpose behind every improvement.
Recorded human response work fell from 268.5 to 17.5 person-minutes, with all 24 needs still covered. That is 251 person-minutes—4 hours 11 minutes—of staff time freed across the response.
A person-minute is one person working for one minute. It measures total recorded staff effort across tasks, including work happening in parallel. The simulator tracks staff workload separately from the time communities wait for aid.