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.
Conflict Early Warning and Early Response 
Excellent post and I completely agree.
Thanks Chris!
Hey Patrick, thank you for the thought-provoking post. I’m passing this on to the rest of the team as well, just to make sure they’ve read it too. One thing to note, though we don’t have the ability yet to flag incidents and/or series of incidents as early warning, we do have the ability to create custom forms within the system. It’s a first-pass at it, but it does work and might be used for a sitrep.
As always, Ushahidi is an open source initiative, so anyone wanting to build in specific functionality can just grab the code and go to town. You can find the code at Github.com/ushahidi
Thanks Erik!
Pingback: Ushahidi: Crowdsourcing for Peace Mapping « iRevolution
Pingback: Ushahidi: Crowdsourcing for Peace Mapping « Conflict Early Warning and Early Response
Interesting post Patrick thanks!
I fully agree with the increasing difficulty to reverse violence, hence the crucial importance of prevention, as well as with the fact that Ushaidi could be a great platform for warning, not only regarding conflict but also many other issues (food security, epidemics and health, water security etc.)
Two comments or interrogations:
1- in section “Sit reports…These SitRep events can be political, social, economic, ecological, historical etc., and should be grouped into such categories.” I am not sure i fully agree with the fact that events and indications (the result obtained from indicators) should be grouped according to those specific categories or to any pre-established category for that matter. In terms of underlying political processes, thus dynamics, i.e. what we need for warning, it seems to me that it would be more efficient to group those events/indications according to the timeline/dynamics of the issue/conflict at hand. For example, some economic events (e.g. brusque inflation on staple food) may go hand in hand with political events (widespread demonstration). If we were ordering events in such a way, then we could follow rising tension and instability and then get better timely warning.
On”triggers:” I know that this is the usual current way to understand conflict dynamics, but i always wonder if the search for triggers is not an elusive quest somehow: once a certain level of tension is reached, on the stage or scene is set for conflict, almost anything can spark violence: it can be a something happening to political leaders, but also a riot, the unfortunate happenstance of the death of someone with a symbolic status, further inflation on some crucial product, an action which will appear strongly illegitimate, increase in oil prices on the global market, etc.
How do you conceptualise and solve this problem?