How Ushahidi Can Become a Real Early Warning Platform

Ushahidi currently uses incident reporting (or more technically event-logging) as the methodology to document violent events that have taken place. While Ushahidi’s use of FrontlineSMS accelerates the crowdsourcing of crisis information, the violence reported on Ushahidi has by definition already occurred and thus cannot be prevented.

This blog post is the first of a two-part series on taking Ushahidi to the next level. The second part in this series  addresses “How Ushahidi Can Become a Real Early Response Platform.”

Current Setup

Ushahidi’s use of SMS to crowdsource crisis information means that violent incidents can be reported in quasi real-time, a significant advantage over traditional conflict early warning systems such as the Horn of Africa’s Conflict Early Warning and Response Network (CEWARN) and the now defunct FAST Early Warning System by Swisspeace.

To be sure, the use of SMS and geo-tagging means that escalating violence can be documented as it happens and where it happens. This can alert organizations of the need to contain or prevent further bloodshed. However, as has been argued by scholars and practitioners, as more blood is spilled the probability of reversing the violence without military intervention grows slim.

Situation Reports

The more robust applied social science methodologies I have come across for field-based conflict early warning combine both incident and situation reporting. Think of them as two types surveys. While the list of indicators in incident reports (IncRep) comprises violent events that seek to be prevented, the list of indicators in situation reports (SitReps) comprises events that are thought to render IncRep indicators more likely.

In other words, if event E is listed on an IncRep, the corresponding SitRep would include events E – t, i.e., those events that usually precede the violent event E in time. These SitRep events can be political, social, economic, ecological, historical etc., and should be grouped into such categories.

However, events E – t that tend to mitigate or prevent events E should also be included in SitReps. We want to know what is going right in order to identify existing entry points for conflict management. Violent conflict is never total in the Clausewitzian sense of total war. There are always pockets of cooperation and intervention. These, however indirect, need to be identified and understood.

SitReps are completed periodically, e.g., on a weekly basis, unlike IncReps, which are completed episodically, i.e., as incidents of violence take place. In other words, regular and consistent situation reporting should be encouraged. SitRep events should be formulated as indicators framed as questions.

For example, “Are university students having their freedom of speech curtailed?” would imply that a regime has acted (an event) to restrict student behavior. This act could elicit student protests and thence “a violent crackdown by government forces,” which would be an IncRep indicator.

SitRep surveys should also use a Likert scale, i.e., answers to SitRep indicator questions should range from “strongly disagree” to “strongly agree.” This means the answers can be weighted. See the CEWARN screenshot above for an operational example of a situation report.

Rationale

Instead of only monitoring incident reports, i.e., violence that has already come to pass, Ushahidi users would be able to monitor and analyze the causal factors themselves to determine whether they are increasing in number and intensity. This could signal potential early warning signs before the causal factors translate into violent events.

As more IncReps and SitReps are completed, users can also empirically assess which SitRep indicators act as the real triggers (and “preventers”) of the violent events documented in IncReps. In addition, after weekly SitReps are completed over several months, they can be aggregated to form a baseline for what the “average” week looks like.

Baseline Analysis

This means that users could then compare each new situation report with the baseline as depicted above. Inflection points, the doted circles, are points of interest since they denote change in trends. The dotted lines represent the threshold beyond which an organization will intervene. Alerts 1 and 2 signal that the threshold has almost been reached.

The important point to note is that baseline analysis of SitRep indicators can identify when the causes of violent conflict are increasing in intensity and frequency. Furthermore, patterns might be identifiable in the causes of episodic conflict and these could inform structural prevention strategies as well as conflict sensitive programming.

Next Steps

It would be great for Ushahidi to at least provide users with the option of setting up their own Situation Report form. I would also recommend that Ushahidi automatically flag when thresholds are crossed. In addition, Ushahidi should integrate some basic statistical techniques so that SitRep indicators (causes and preventers of conflict) could be automatically flagged when they are statistically correlated with IncRep indicators, i.e., violent events.

The purpose of including SitReps in Ushahidi is to encourage evidence-based programming and make early warning less of a hypothetical possibility.