Kinga

Forecasts are fast now action isn't. Kinga turns disaster protocols into live triggers that auto-dispatch over mesh networks and track who acts, before disaster strikes.

Comment

Inspiration

Every year, the Horn of Africa gets faster, more accurate forecasts and disasters still cost the same lives. That contradiction is the whole project. ICPAC, the IGAD region's own climate center, moved its infrastructure to Google Cloud and cut warning-issuance time from eight hours to thirty minutes. Google's Flood Hub now reaches hundreds of millions of people with AI-driven flood forecasts. Prediction is a solved, well-funded problem.

And yet ICPAC's own technical reporting on a recent flood said the impacts showed "gaps in preparedness and early action despite early warning information being availed on time." That sentence is where Kinga started. The bottleneck isn't the forecast. It's everything that's supposed to happen after it.

The moment that sealed it for us: IGAD is currently paying a consultant to manually reconstruct five years of Anticipatory Action activation history, by hand, across eight countries because no system exists that tracks it automatically. We didn't want to pitch a hypothetical problem. We wanted to build the thing that consultant is being paid to simulate.

What it does

Kinga is an anticipatory-action trigger and activation engine. It takes disaster-response protocols that currently live in PDFs hazard, threshold, pre-agreed action, responsible institution and turns them into structured, continuously monitored data.

  • Monitors live hazard indicators (rainfall, river level, NDVI, seasonal forecast probability, IPC phase) against every defined trigger.
  • Anticipates — an LSTM forecasts whether a threshold is likely to be crossed in the next 7–14 days, giving response teams extra lead time before the hard rule fires.
  • Activates — when a trigger fires, Kinga dispatches a pre-agreed action checklist to the responsible institution over a mesh relay network that keeps working even if the cellular network is down, which is often exactly when it matters most.
  • Reaches the last mile — once the institution acknowledges, a simplified, multilingual message fans out to community contacts, so the loop doesn't stop at the institutional door.
  • Tracks accountability — every dispatch, hop, and acknowledgment is timestamped. An anomaly model flags institutions trending toward a missed deadline before they miss it, so the system can auto-escalate.
  • Shows it all in a "Situation Room" dashboard: a trigger status map, live threshold gauges, an activation timeline replay, and an institutional responsiveness scorecard.

How we built it

We started from evidence, not assumptions grounding the trigger schema in real Forecast-based Financing protocols published by WFP and the Start Network, so our demo data traces back to actual pre-agreed thresholds rather than invented numbers.

The backend is Python and FastAPI, chosen so the same build gives us auto-generated OpenAPI docs for free useful both for our own iteration speed and for the judging panel. The anticipation model is a TensorFlow/Keras LSTM trained on synthetic time series generated to match the schema of real sources (CHIRPS rainfall, MODIS NDVI, NASA POWER soil moisture), so the whole pipeline runs and demos correctly without depending on venue wifi or API keys mid-pitch. The mesh relay is a NetworkX graph simulation, villages and field offices as nodes, radio range as edges, with hop latency and node dropout modeled so we could show delivery rerouting around an offline node without needing physical LoRa hardware. The dashboard is a single-file HTML/CSS/JS build with an SVG map, deliberately dependency-light so we could keep iterating under time pressure without a build step.

We treated the data-source unevenness as a feature to document rather than a bug to hide: some feeds (soil moisture, near-real-time rainfall) are genuinely live; others (CHIRPS, NDVI, IPC phase) update on cadences from 16 days to several months. Normalizing all of that into one trigger schema is itself a piece of the fragmentation problem we're solving, so we built the system to be honest about it.

Challenges we ran into

The hardest design decision wasn't technical, it was scope. It would have been easy to build "another flood prediction model" the exact thing we decided not to compete on, since Google and ICPAC already do it well. Staying disciplined about consuming forecasts as an input rather than trying to out-predict them took more restraint than building a flashier model would have.

Network access during a hackathon is also its own adversary. Earth Engine, CHIRPS, and NASA POWER endpoints are not reliably reachable from a constrained dev environment, so we built a synthetic-first data layer that's schema-identical to the real sources meaning the model, mesh simulation, and dashboard all demo correctly offline, with clearly marked swap-in points for live data post-hackathon.

We also had to resist the instinct to stop at the institution. Early versions of the activation flow ended at "responsible institution acknowledges" but that leaves out the people the warning is actually supposed to protect. Extending the pipeline one more hop, to a community broadcast tier with its own lightweight acknowledgment channel, was a late but necessary addition once we re-read the brief's emphasis on trust and last-mile reach.

Accomplishments that we're proud of

We're proud that every number in our demo traces back to something real: a real ICPAC quote, a real IGAD procurement document, real FbF protocol thresholds. It would have been faster to invent a clean synthetic story; grounding it in evidence made the pitch harder to build and much harder to dismiss.

We're also proud of the trigger schema itself. It's hazard-agnostic by design the same JSON structure that encodes a drought trigger in Marsabit County works unchanged for a flood trigger in Jubaland. That portability across hazards and across all eight IGAD member states is, in miniature, the exact standardization problem the region's own AA working groups are trying to solve.

What we learned

We learned that the most valuable technical work in a crisis-response system often isn't the model, it's the plumbing. The LSTM matters, but the mesh relay, the acknowledgment tracking, and the escalation logic are what actually determine whether a warning becomes an action. We came in expecting to spend most of our time on forecasting; we left having spent most of it on delivery and accountability, which is exactly where the evidence said the real gap was.

We also learned to read a brief for what it implies as much as what it states. "Reach the last mile" and "trust" are easy to nod at and easy to under-build; going back and adding the community broadcast tier and the plain-language rationale field made the project noticeably more honest about who a warning is actually for.

What's next for Kinga

  • Wire the swap-in points to live: Earth Engine for CHIRPS/NDVI, GloFAS for river discharge, and Africa's Talking for real SMS/USSD delivery alongside the mesh layer.
  • Pilot the community feedback channel with a real USSD short code in one admin unit, so "acknowledged" and "acted" can be measured at the community level, not just the institutional one.
  • Layer real GIS data (population density, IPC phase boundaries) under the trigger map so exposure, not just trigger state, is visible at a glance.
  • Work with IGAD's Regional Technical Working Group on Anticipatory Action to validate our trigger schema against the cross-border trigger matrices they're already standardizing, so Kinga complements existing coordination work rather than sitting outside it.

Built With

Share this project:

Updates

Submission history