-
The welcome page is designed to take into consideration that GPS might not work
-
How a conversation looks, You don't need to hold back or limit to fixed options
-
Quickly summaries the conversation while for indexing
-
Horizontal help, takes into consideration the community service you might wish to do according to your convience.
-
Vertical help, NGO or Government agency can easily see how and what they can do to help.
-
Empowering for long term sustainability
Inspiration
The project is addressing an ugly reality of the world: War. The struggle for power between countries brings suffering to the innocent. Unfortunately people are getting displaced all too often, irrespective of their involvement or alignment with the cause. When someone is forced to move out of their habitat, it's hard sustaining even in ideal conditions — and these are far from ideal. To add insult to injury, lives are lost. Sometimes a dear one is lost or missing in action. If he/she is the sole breadwinner, it adds financial strain on top of mental trauma.
During ideation we noticed there is a triangle of information flow. Every section wants to help — the displaced, their neighbors, and the NGOs/donors. The real limitation is the lack of organized information. Until now we've used methodical information-gathering strategies, starting with word of mouth (limited reach, and facts distort as they move up the ladder) and online forms (large reach, but limited options — a fixed set of checkboxes dumped into spreadsheets, then aggregated in a way that loses attention to the individual). Fortunately we have two amazing technologies at hand. We can combine the scale of online forms with the individual attention of personal methods. AI makes this possible.
What it does
HOPE (Humanitarian Operations Platform for Empowerment) replaces rigid intake forms with an empathetic AI that listens, then turns what it hears into action. It closes all three sides of the information triangle:
Empathetic intake (information flowing up): Instead of "tick a box," a displaced person simply talks. The AI captures their name, the human-described location of their shelter, their needs (food/shelter/children/medical), and — crucially — their skills, then structures it into clean, queryable data. No more "row 847." Neighbor-to-neighbor matching (information flowing sideways): HOPE matches a person's skills against the most vulnerable nearby needs. An electrician isn't just "registered" — he's pointed to the widow's roof and the water pipe serving 40 people, ranked by human-described proximity and social need. Donor & NGO clarity (information flowing down): A dashboard shows ranked community needs and exactly which gaps neighbors can cover vs. which need funding — so every dollar closes the last gap, not a duplicated one.
How we built it
The design philosophy was maximum impact, minimum moving parts. Three pieces do the work of a dozen:
One conversational AI (MiniMax-M3 via TokenRouter) handles intake, extraction, and the dashboard Q&A — the same empathetic interface serves displaced people and coordinators. One data layer (Redis Stack + RediSearch) is simultaneously the database, the cache, and the semantic search engine — using local BGE-small embeddings so matching runs without external API calls or quota. One thin React/Vite frontend with streaming responses, talking to a small FastAPI backend (/chat, /chat/stream, /intake/save, /dashboard/ask). The elegance is in what we didn't add: no GPS stack, no microservice sprawl, no heavyweight ML pipeline. Each layer earns its place by doing more than one job, and the whole thing runs as a reproducible Docker Compose sandbox.
Why human allocation instead of GPS This is a deliberate, field-driven choice. In a war zone, GPS is unreliable — signals are jammed, degraded, or deliberately constrained, and devices may be offline. Worse, displacement shelters and huts are packed so close together that GPS resolution can't tell one from the next — coordinates would point to "somewhere in that cluster of ten families," which is useless for sending the right neighbor to the right door.
So HOPE allocates the way humans actually do: by landmarks and relationships — "the blue tent past the water tank," "two rows behind the clinic." The AI captures these human descriptions during intake and reasons over relative proximity and social need instead of latitude/longitude. It's not just a fallback for missing GPS; in a dense camp it's more accurate and more humane than coordinates.
Observability: Sentry + Arize (and why they matter) For a tool people may depend on in a crisis, reliability is a feature, so we instrumented HOPE for observability from day one:
Sentry (frontend + backend) gives us real-time error and performance monitoring. If an intake fails or an endpoint slows down, we see exactly where and why — stack trace, request, and timing — instead of a frustrated user silently dropping off. In a humanitarian context, a silent failure can mean a need that never gets recorded; Sentry makes those failures loud and fixable. Arize gives us LLM observability — every model call is traced (inputs, outputs, latency, token usage). Because the entire product hinges on an LLM correctly extracting needs and skills, Arize lets us catch hallucinations, drift, and bad extractions, and continuously evaluate prompt quality. It turns "the AI feels off today" into measurable, debuggable data. Together they mean HOPE isn't a black box — it's monitored, measurable, and trustworthy, which is exactly what an aid tool has to be.
Challenges we ran into
Keeping it simple was the hardest part. The instinct on a humanitarian problem is to build everything. Resisting scope creep — distilling the triangle of information flow into three clean features and one conversation — took more discipline than code. Every feature had to justify itself against "does a person in a tent actually benefit from this?" Latency. Blocking LLM calls made /intake/save and the dashboard feel sluggish (5–11s of dead air). We re-architected around a streaming endpoint that strips the model's internal reasoning on the fly and emits tokens progressively, so responses appear word-by-word. We couldn't reduce raw generation time, but we made the wait feel instant — critical when your user has limited patience and limited battery. Designing Redis for many communities and for scale. A single camp is easy; the real question is how does one index serve dozens of communities without cross-contamination? We designed the schema so each community is namespaced/partitioned, and matching queries are scoped to a community before semantic search runs — so an electrician in one camp is never matched to a roof in another. Because Redis Stack handles vector search, caching, and storage in one engine, scaling out means scaling one component, not four. Connecting the community. Deciding how neighbors actually link up — who sees whose need, how a match is proposed, how trust is preserved — was a genuine product problem. We anchored it on the human-proximity model so connections feel natural and local, not algorithmic and anonymous. Conveying what is needed to the community. A need in a database is worthless if the right person can't understand it. We focused on translating structured gaps back into plain, human, actionable asks ("the widow two tents over needs her roof patched before the rain"), so the loop from need → match → action closes in language people actually use.
Accomplishments that we're proud of
A working, deployed full stack — not a slide deck. A genuinely elegant, minimal architecture where every layer does double duty. A field-realistic human allocation model that works precisely where GPS fails. Full observability (Sentry + Arize) baked in from the start — reliability treated as a first-class feature. Reframing displaced people from "recipients in a spreadsheet" to active contributors — a self-healing community.
What we learned
Empathy is an interface. Letting people speak instead of filling forms captures richer, truer data — including skills nobody thinks to ask about. Constraints breed better design. Dropping GPS for human landmarks wasn't a compromise — it was the right answer for the environment. Simplicity is engineering, not laziness. The discipline to keep the app small is what makes it deployable and understandable. Stream everything when LLMs are in the loop; perceived latency is latency. You can't fix what you can't see — Sentry and Arize turned vague worries into concrete, actionable signals.
What's next for HOPE
Voice-first intake in the field, offline-tolerant, in local languages. Smarter human-proximity routing that learns landmark vocabulary per community. Multi-community dashboards for NGOs coordinating across camps. Donor funding loop so a coordinator can fund a matched task directly. Pilot with a partner organization using anonymized, consented data.
Log in or sign up for Devpost to join the conversation.