Data Does Not Speak for Itself
A quiet belief runs through much of Tech-based works.
If we collect enough data, reality will become clearer. If we map enough incidents, patterns will emerge. If we gather enough responses, communities will be understood.
There is truth in this. But there is also a risk. A big risk.
Because data does not speak for itself. And the tools we use to collect it are never neutral.
Before data exists, choices are made. Every reporting system, survey, or dashboard begins with decisions.
What counts as an incident? What categories are available? What questions are asked? What language is used? What fields are required?
These decisions are necessary. Without them, the system cannot function.
But they are not neutral. They define what reality looks like inside the system.
Let me give an example.
A reporting system categorized incidents into predefined types such as armed clash, theft, threat, movement restriction. But local communities described situations differently. For some, the most important issue was fear of traveling after dark, uncertainty about which authority to follow, tension that had not yet become violence. Many are not an event but conditions.
These did not fit neatly into the system. So they were either forced into "other" categories or not recorded at all.
The system worked. But part of reality was filtered out.
This is not a failure of technology. It is a characteristic of it. Technology requires structure. But structure always simplifies.
The same number can cover many meanings.
Consider surveys.
A digital survey asks: "Do you feel safe?"
Respondents choose: yes, no, somewhat.
The results are aggregated. The dashboard shows: 40% feel safe, 35% somewhat safe, 25% unsafe. It looks clear.
But what does "safe" mean?
For some, no armed presence. For others, protection from armed actors. For some, economic stability. For others, freedom from fear.
A single number cannot capture this. It compresses. And this compression is often invisible. Once data is produced, it appears objective. It looks comparable, visualizable, reportable. But the assumptions that shaped it rarely appear alongside the output.
Here the problem shifts from collection to interpretation.
This is the points that many researchers already understood. Quantitative data have challenges for interpretive depth while qualitative data have challenges with generalizability. In the age of limited attention and limited safety, what challenges would seem replicating?
In conflict settings, this becomes more complex.
People do not always report what they experience. They report what they can safely say. Or what they think will be understood. Or what they believe is expected. Sometimes we saw a reporting system with very low incident numbers. At first glance, it looked like stability. But when we spoke to community members, a different picture emerged.
People did not report incidents because they did not trust how the information would be used. They feared being identified. They did not believe reporting would change anything. Silence entered the data. But the system recorded it as absence.
This is a common problem. Absence of data is often read as absence of issue. But in many cases, it reflects fear, lack of access, exclusion, or distrust.
Let me make this concrete with an example.
In a digital consultation process, participants ranked priorities for community development. The options were: infrastructure, education, security, livelihoods.
Participants selected. Results were analyzed. Security ranked high.
But in real conversations, it became clear that "security" meant very different things. For some, fewer checkpoints. For others, stronger protection. For some, resolving land disputes. For others, addressing domestic violence.
The category had grouped these together. The system produced a result. But the meaning inside that result remained fragmented.
This is where PeaceTech becomes more than mere "technical". It becomes interpretive. And interpretation is never neutral. It is shaped by who designs the system, who defines categories, who analyzes results, and who decides what matters. These are political decisions, even when they appear technical. Narrative data presents a different version of the same problem.
Let's check a more legitmate study. The Stanford-MIT joint research project, anchored by the creation of the DeliberationBank dataset, serves as a sobering look at the limitations of artificial intelligence in democratic processes. By collecting 3,000 unique participant opinions on ten sensitive policy questions and processing them through 18 different large language models, the researchers sought to determine if AI could act as an impartial clerk for human discourse. While the models excelled at producing summaries that sounded professional and balanced, a rigorous audit of 4,500 human judgments revealed a "fluency trap." The LLMs consistently prioritized the most common arguments, systematically filtering out minority perspectives and unconventional stances. This trend suggests that while AI can synthesize information efficiently, it tends to reinforce a "tyranny of the majority" by neglecting the nuance of dissenting voices, ultimately rendering current models a risky choice for high-stakes deliberative contexts where every perspective counts.(Pei et al., 2025)
This is not a failure of the tool. It is a feature of summarization. To summarize is to reduce. To reduce is to select. To select is to interpret. The problem is not that interpretation happens. It always does. The problem is when interpretation becomes invisible. What we can do differently?
This does not mean we abandon data or tools. It means we use them differently. We ask. What assumptions are built into this system? What realities does it privilege? What does it leave out? Who can question its outputs?
And perhaps most importantly this question. What decisions are being made based on this data?
In practice, this often means:
Combine quantitative data with narratives – numbers alone hide too much.
Document how categories are defined – make assumptions visible.
Ask what terms mean to different groups – do not assume shared meaning.
Preserve disagreement instead of smoothing it – contradiction is information.
Make uncertainty visible in reporting – do not hide what you do not know.
One practical shift is simple.
When presenting data, add a second layer. Not only "What does the data show?" but also "What might this data be missing? Who might not be represented? How might this be interpreted differently?" This does not weaken the data. It strengthens its usefulness, because it prevents false confidence.
PeaceTech can make conflict more visible. But it can also make it appear more stable, more simplified, more resolved than it actually is. If we do not pay attention, we risk building systems that are efficient but misleading.
Data does not remove the need for judgment. It increases it. Because the more we rely on data, the more important it becomes to understand how it was shaped—and what it cannot show.
In peacebuilding, acting with partial understanding is unavoidable. But acting as if that understanding is complete is where the real danger begins. So the question is not only whether a tool works. It is what version of reality that tool produces. Because acting on the wrong version of reality can create harm. Even when everything else is done correctly.