Inspiration

During a disaster, the problem is often not a lack of information. It is an overwhelming flood of fragmented information arriving through SMS messages, messaging apps, field reports, radio updates, forms, and informal community channels.

The same incident may be reported several times, important facts may conflict, urgent medical needs may be hidden inside unstructured text, and decision-makers may not know which information is current or trustworthy. At the same time, relief resources such as boats, medical teams, shelter capacity, water, fuel, and transport are limited.

ReliefQueue AI was built to help response teams transform this information flood into an accountable, human-reviewed operating queue.

What it does

ReliefQueue AI converts fragmented, multilingual disaster reports into a structured and prioritized relief workflow.

It provides three connected operational experiences:

  • Command Center: reviews incoming reports, incident clusters, workload pressure, advisory analysis, and shared operational visibility.
  • Local Coordinator: reviews local context, worker suitability, geographic constraints, AI or deterministic guidance, and records the final human operational decision.
  • Field Worker: receives assigned work, records progress, and submits field observations back into the shared workflow.

The system can:

  • Group duplicate or related reports into incident clusters.
  • Normalize multilingual and noisy reports.
  • Preserve source provenance and conflicting information.
  • Surface urgent needs, missing facts, and questions requiring verification.
  • Provide advisory analysis without granting AI dispatch authority.
  • Maintain deterministic fallback behaviour when an AI-provider response cannot be safely accepted.
  • Keep human review mandatory before operational decisions.
  • Show the handoff from information intake to coordination, field execution, and accountable review.

How we built it

The user interfaces were built with React, TypeScript, and Vite. A Python Product API provides the shared workflow, deterministic processing, advisory boundaries, temporary operational state, and AI-provider integration.

The public frontend is deployed on Cloudflare Pages, while the backend is deployed on Render. The current public deployment is configured to use Fireworks AI through an OpenAI-compatible API. Provider responses are accepted as verified live results only when the required transport, structure, provenance, and nonce-binding checks pass. Otherwise, the system clearly labels and uses its deterministic safe fallback.

During development, we also completed a verified historical inference campaign using AMD Developer Cloud, an AMD Instinct MI300X accelerator, ROCm-compatible infrastructure, and vLLM. ReliefQueue preserves this separately as historical evidence rather than presenting it as the provider for every current request.

The architecture also includes reviewed boundaries for geospatial context, queues, field forms, messaging integrations, observability, privacy checks, backups, and degraded operation.

Human-review and safety boundary

ReliefQueue AI is deliberately advisory.

The Command Center cannot silently assign workers, dispatch teams, close incidents, or alter authoritative operational status. Those decisions remain with the Local Coordinator. Field-worker observations are also treated as reports requiring appropriate review rather than automatically becoming authoritative state.

Synthetic demonstration data is used in the public application, and the interface clearly distinguishes:

  • deterministic guidance,
  • configured AI capability,
  • historical provider evidence,
  • current-request verification,
  • fallback output, and
  • final human decisions.

Challenges we faced

One major challenge was maintaining truthful AI provenance across different deployments. A configured provider is not automatically presented as verified live. Each request must establish its own verification state.

Another challenge was connecting a Cloudflare-hosted frontend to a separately deployed backend while ensuring every browser API request reached the correct public API rather than the frontend's single-page application fallback.

We also had to preserve a clear authority boundary across three roles while sharing case state, decisions, advisories, and field reports.

Finally, the system needed to remain useful when an external AI provider, network connection, geospatial service, or queue integration was unavailable.

Accomplishments

We are proud that ReliefQueue AI now provides:

  • An end-to-end disaster-response workflow across three operational roles.
  • A guided seven-step judge walkthrough.
  • Multilingual and multi-source intake demonstrations.
  • Provider-neutral current-runtime labelling.
  • Historical AMD/vLLM evidence that remains clearly separated from the current deployment.
  • Deterministic degraded-mode operation.
  • Human-review and privacy boundaries embedded directly into the product.
  • A public application and public source repository.
  • A final repository validation run in which all 358 automated tests passed.

What we learned

The most valuable use of AI in disaster coordination is not replacing the decision-maker. It is reducing information overload, structuring uncertainty, preserving evidence, and helping people identify what must be verified next.

We also learned that trustworthy AI interfaces need to explain not only what an AI system produced, but also where it ran, whether that particular request was verified, whether fallback was used, and who retains final authority.

What's next

The next steps are to add durable database-backed operational state, strengthen offline-first field synchronization, integrate real humanitarian communication channels, conduct broader multilingual evaluations, and pilot the workflow with emergency-response and community-relief stakeholders.

The long-term goal is a deployable, open, human-governed coordination layer that helps limited relief resources reach the right people faster.

Built With

Share this project:

Updates

Submission history