RelayAid

Inspiration

After a disaster, people who need help send requests through calls, texts, and word of mouth, and many of those requests are lost before anyone can act on them. We wanted a single place where every request stays visible, from the first report until help is confirmed, so residents, coordinators, and responders all see the same picture.

What it does

RelayAid is a disaster response web app at relayaid.us. It has three views, one for each role:

Residents submit requests for help (/r/request) and get a receipt they can track.
Coordinators triage incoming requests in a shared queue (/c/queue).
Volunteers and responders claim and complete tasks (/v/tasks).

A receipt only moves forward when the server confirms the change, so no one sees progress that didn't actually happen. An offline outbox holds requests until the connection comes back. A server-side NVIDIA Nemotron integration powers Investigate, which helps plan a response to a case once the model is configured. Model credentials stay on the server and never reach the browser. When no model is available, Investigate falls back to a clearly labelled deterministic plan.

The latest code adds an orchestration layer that applies queued policy jobs to cases, keeps case state on disk, and includes a sandbox with referral workflows for testing handoffs to emergency services. Those services are synthetic, for demo purposes only. RelayAid isn't connected to 911 or any real emergency agency.

How we built it

Front end: React and TypeScript, built with Vite and Tailwind CSS.
Shared state: SpacetimeDB keeps the request queue and task state in sync across roles in real time.
Gateway: a Node/TypeScript gateway (services/gateway) with separate modules for auth, model calls, orchestration, and referrals. Zod validates data passed between modules.
Investigate: NVIDIA Nemotron, called only from the server.
Local startup: a single local dev script starts the gateway, the synthetic-service sandbox, and the site together.

Challenges we ran into

Honest status under poor connectivity. Showing optimistic progress is easy, but in a disaster a false "help is on the way" is dangerous. We built the receipt flow around server confirmation and an offline outbox.
Keeping AI on the server. We kept model keys and calls out of the browser bundle and designed a fallback so the app stays useful without a model.
Separating roles. Residents, coordinators, and volunteers need different views and permissions while sharing one source of truth.

Accomplishments that we're proud of

We built a multi-role response desk where every request stays visible, plus a server-side NVIDIA Nemotron integration with a clearly labelled fallback. We also built a synthetic emergency-services sandbox with referral workflows and a one-command local startup for the whole stack. Our demo link is relayaid.us.

What we learned

We learned that in emergency tools, being clear about what is confirmed matters more than speed. A clearly labelled fallback beats a confident wrong answer. Real-time shared state also removes much of the coordination overhead that slows response down.

What's next for RelayAid

Verify and harden voice and video calling between people and agents, including agent callbacks when no human is available.
Expand autonomous case handling, keeping clear audit trails.
Add location sharing for residents who opt in.
Harden production authentication and deployment.
Extend and validate the synthetic-service workflows before any integration with a real agency.

RelayAid is a hackathon prototype. Its emergency-services integration is a demo, and it hasn't been tested in a real disaster.