Sauti ya Tahadhari

Inspiration

ICPAC already generates strong early-warning signals for droughts, floods, locust swarms, and food insecurity across the Horn of Africa—Hazard Watch, Drought Watch, HUSIKA, and a Thresholds & Triggers system are all live today. The gap I noticed wasn't detection. It was the last mile: turning a technical hazard bulletin into something a pastoralist with a basic phone or a district disaster officer juggling five other emergencies can actually understand and act on before it's too late. "Transforming information into action" are the theme's own words—I took that literally as the whole product, not a tagline.

What it does

Trigger → Understand → Act takes a structured hazard trigger (hazard type, severity, location, threshold crossed, and timeframe) and generates two synchronized outputs from the same event: a short plain-language public warning and a role-specific action checklist for local officials. Both come from one trigger, so the community and the responders coordinating on their behalf are working from the same facts at the same time.

The core safety guarantee: every critical fact—hazard, location, threshold, timing—is locked to the source and never touched by the AI; only the surrounding language is generated. An independent validator checks this on every single output, and the result is visible live in the UI as a pass/fail state next to a side-by-side view of locked source facts versus AI-generated language — not just a claim in a README.

How I built it

A FastAPI backend exposes POST /pipeline/run as the core endpoint: trigger in, validated dual output out. The AI layer is provider-agnostic by design—a single `LLMProvider "interface with interchangeable Anthropic, Gemini, and OpenAI implementations, switchable via one environment variable, so the product isn't locked to (or broken by) any single vendor. The prompt uses constrained generation: the model is instructed to echo safety-critical facts verbatim and generate only the natural-language framing, and a separate validator function independently re-checks every output field-by-field against the source trigger before anything reaches a user.

The frontend is Next.js, deployed on Vercel, calling the backend (deployed on Render) directly. Sample trigger data spans four hazard types—drought, flood, locust, and food insecurity—modeled on ICPAC's documented hazard schema, disclosed honestly as sample data rather than a live feed given the hackathon's timeframe.

Challenges I ran into

The most instructive challenge was provider reliability under real-world conditions: I hit an OpenAI quota error, then two different Gemini model-availability errors in quick succession as Google's free-tier model list shifted under me, and finally a token-truncation bug caused by newer Gemini models spending part of their output budget on hidden "thinking" tokens before writing the actual answer—silently truncating the JSON mid-string. Building the provider-agnostic architecture before hitting these issues is what let me swap providers via one config value instead of rewriting the pipeline under deadline pressure, working solo with limited time.

Accomplishments that I'm proud of

Getting the fact-locking guarantee to be something you can see pass or fail in the interface, not just something I assert in a slide. Getting a fully working, publicly deployed prototype live—real AI generation, real validation, and real deployment—across four distinct hazard types with consistent validator passes as a solo builder under a tight deadline.

What I learned

That the hardest part of "AI for early warning" isn't the AI — it's making the AI's safety guarantees legible and verifiable to someone who didn't write the code, in the few seconds a judge (or a disaster response officer) has to trust it.

What's next for Sauti ya Tahadhari

Integrate directly with ICPAC's live Thresholds & Triggers data instead of documented sample events; add real voice/SMS delivery for offline, non-smartphone users; expand to additional local languages; and build out the officer dashboard so district teams can track which actions have actually been taken in response to a trigger.

Built With

• anthropic-claude
• fastapi
• generative-ai
• google-gemini
• javascript
• llm
• nextjs
• openai
• pydantic
• python
• react
• render
• rest-api
• vercel