CrisisFeed | Devpost

Inspiration

Food crises rarely happen without warning. The signals usually appear early — rainfall shocks, conflict escalation, food insecurity trends — but responders often have to piece them together manually, across fragmented reports and disconnected tools.

We were especially struck by the gap between "early signals" and "early action". In many crisis-prone regions, the question is not just where conditions are getting worse, but also who will be affected first and what kind of support should be prioritized. Existing systems often stop at monitoring. We wanted to build something more actionable.

That led us to CrisisFeed: a system that turns fragmented crisis signals into an operational early warning workflow.

What it does

CrisisFeed is a two-layer food crisis early warning system.

Layer 1: Crisis Forecast

It predicts which regions are likely to experience food crisis escalation in the next 7–14 days.

Layer 2: Nutritional Vulnerability Overlay

Within those high-risk areas, it identifies which populations are likely to become nutritionally vulnerable first and what kind of support should be prioritized.

In short, CrisisFeed helps responders answer three questions:

Where is risk rising?
Who is most vulnerable?
What kind of response should be prioritized?

For the hackathon MVP, we focused on Haiti and Sudan, aiming toward an admin1-level workflow that can eventually support earlier, more targeted humanitarian action.

How we built it

We designed CrisisFeed as a two-layer decision-support system:

1. ML-based crisis prediction layer

We structured the forecasting problem around regional food crisis escalation, using signals such as:

conflict events and fatalities
food security baseline trends
rainfall / climate stress
food price pressure when available

Our intended modeling unit was:

[ \text{country} + \text{admin1} + \text{time window} ]

We explored a lightweight, interpretable ML approach so that the output could be translated into a risk score and surfaced in a way decision-makers could actually use.

2. Rule-based Nutritional Vulnerability Index (NVI)

Instead of training a second model without reliable labels, we built an expert-informed rule-based layer to prioritize vulnerable groups. This layer uses nutrition and health indicators such as:

child wasting / acute malnutrition
birth rate as a maternal burden proxy
diabetes prevalence
under-5 population share

This gave us a practical way to move from prediction to response prioritization.

Product and prototype

On the product side, we built the MVP around a simple response flow:

View a region-level risk signal
See key drivers behind the alert
Identify vulnerable populations
Trigger a local response workflow

We used a combination of:

machine learning / data processing
public crisis and nutrition datasets
a frontend prototype for region-level interaction
documentation and open-source style project structure

Challenges we ran into

The biggest challenge was data integration under severe time pressure.

We were trying to combine multiple public datasets that differed across:

spatial granularity
time frequency
country coverage
naming conventions
ease of access

For example, some sources were event-level, some were monthly, and some were country-level while others were closer to admin1. Aligning those into one coherent forecasting pipeline was much harder than building the concept itself.

Another major challenge was deciding what not to build. We had to constantly reduce scope and focus on the most important question: what is the minimum prototype that proves the idea is useful?

We also had to be careful not to overclaim precision, especially on the nutrition side. That is why we chose a rule-based vulnerability layer rather than pretending we had enough data to train a fully reliable second predictive model.

Accomplishments that we're proud of

We are proud that we did not build just another dashboard.

What we built is a clear decision framework:

forecast regional food stress
prioritize vulnerable populations
translate signals into response logic

We are also proud of the product framing itself. CrisisFeed is not just about warning that “something bad may happen.” It is about making those warnings more operational and more humane.

Technically, we are proud that we were able to:

define a realistic forecasting problem
structure a two-layer system with clear logic
differentiate prediction from vulnerability prioritization
build toward an actionable MVP under hackathon constraints

What we learned

We learned that in humanitarian tech, clarity and actionability matter as much as model sophistication.

A powerful insight for us was that there are really two separate problems:

forecasting where crisis risk will escalate
prioritizing who will need the most appropriate support first

Those should not necessarily be solved with the same method.

We also learned that public data is both a huge opportunity and a major engineering challenge. Open datasets make systems like this possible, but operationalizing them requires thoughtful decisions about granularity, alignment, and interpretability.

Most importantly, we learned that a good crisis tool should not stop at prediction. It should help people decide what to do next.