The first EASF meeting we attended, we were one of three software vendors. The other two had spent the intro explaining what they did. We'd spent ours asking questions, specifically, we'd read the EASF Concept of Operations document before we arrived, which apparently almost nobody external does. That's what got us the second meeting.
What follows is an account of what we learned in the meetings after that, and what we built. Lindela is intelligence software for peacekeeping operations, a domain where the design decisions carry weight that most software does not. We're writing this because we think the problem is important, the engineering is honest, and some of the questions the project forced us to answer are ones the industry needs to talk about in public rather than behind NDAs.
The Intelligence Gap
Existing systems, the ones with actual track records in field operations, were built for NATO-style symmetric conflict. State versus state. Defined front lines. Structured order of battle: brigade, battalion, company, platoon, named commanders, known equipment. The data models in Western intelligence platforms assume that the primary entities in a conflict are sovereign military formations, and that those formations have the kind of organizational legibility a researcher can encode in a relational schema.
East African conflict is different in ways that are structural, not incidental.
It looks like pastoralist clashes over water and grazing land that spike seasonally when the rains fail, erupt across a border, and then subside, leaving no order of battle to track, no combatant to de-mobilize, no front line to negotiate. It looks like cross-border cattle raiding between communities that have conducted the same raids for generations, occasionally with firearms that weren't there a generation ago. It looks like non-state armed groups with no formal structure, loose networks of fighters whose affiliation shifts based on who is paying, whose cattle were taken, what a particular elder decided last week. It looks like criminal networks that blur into political militias, where the same individuals move between commercial crime and political violence depending on the electoral calendar and who is in government.
The data models in Western intelligence systems don't have the right ontology for any of this. When every actor needs to be a unit with a chain of command, and every incident needs to be a kinetic event in a linear conflict, the system becomes structurally incapable of representing what is actually happening. You end up with analysts doing sophisticated pattern analysis in their heads, in spite of their tools rather than with them.
We spent three months on ontology before we wrote a line of application code. The entities in Lindela's data model are incidents, locations, communities, organizations, individuals where relevant and scoped, environmental conditions, particularly rainfall, pasture quality, and water availability, which are genuine predictors of pastoral conflict, and the typed relationships between them. The schema is a graph. The analysis layer reasons over that graph. The reporting layer projects from that graph into the structured document formats that commanders actually consume.
Data Architecture: The Deconfliction Problem
Lindela ingests from multiple open-source feeds alongside classified channels. GDELT gives you global event data, useful for political violence tracking and media coverage analysis, but noisy. ACLED is better curated, with field researchers reviewing each record, but carries a 48-to-72-hour lag for East Africa. OpenStreetMap gives you terrain and infrastructure, but coverage is incomplete in the rural areas that matter most: the water points, the seasonal grazing corridors, the market crossings where conflict concentrates are frequently absent. The classified feeds we can't discuss publicly, except to say the integration pattern is the same: normalized confidence scores, explicit source hierarchy, analyst-in-the-loop for ambiguous cases.
The challenge isn't ingestion. Any competent data pipeline can consume a REST API or parse a CSV. The challenge is deconfliction: what you do when two authoritative sources describe the same event differently.
When GDELT says an event happened at location A on Tuesday and ACLED says it happened at location B on Wednesday, and they are describing the same incident, you need explicit, documented rules for which you trust and why. That question doesn't have a universal answer: it depends on the event type, the geographic area, the specific source characteristics, and sometimes the analyst's ground-truth knowledge. What it cannot be is implicit. A system that silently picks a winner discards information. A system that surfaces both versions with their provenance keeps the uncertainty visible, which is what the analyst actually needs to assess confidence in a report.
We implemented a source-weighted confidence model. ACLED records receive higher base confidence than GDELT for community-level violence events. Geographic proximity within a configurable radius and temporal proximity within a configurable window trigger a merge candidate. A human analyst reviews merge candidates above a conflict threshold and resolves ambiguous cases. The resolution decision is logged with the analyst's identity and reasoning. Not because we distrust analysts, because the audit trail matters when a report built on that data eventually informs an operational decision that affects people's lives.
The 188 Report Templates
These weren't designed by software engineers. We embedded a product designer with the EASF J2 team for six weeks before we built the template system. The difference between a SITREP and a TACSIT illustrates why that mattered.
Both are situation reports. From outside the operational hierarchy they look similar, structured summaries of what is happening. From inside, they are completely different documents serving completely different functions. A SITREP goes to strategic command and needs political context: what are the implications for the mandate, what are the escalation risks, what decisions does strategic command need to make in the next 72 hours? A TACSIT goes to field commanders and needs immediate-action relevance: where are the threat actors right now, what are their likely axes of movement, what are my own forces' positions relative to those axes?
The audience for a SITREP is making resource allocation decisions measured in weeks. The audience for a TACSIT is making movement decisions measured in hours. A system that treats these as "a report with fields" will produce documents that satisfy neither audience.
Our designer's job for six weeks was to understand each of the report types in the J2 workflow: who writes them, who reads them, what decisions they support, what fields are mandatory versus contextual, and how the language conventions differ by report type and by audience echelon. Several fields in the existing Word templates turned out to be vestigial, inherited from UN formats decades old that no longer matched the EASF command structure. We documented those and got explicit sign-off to remove them. Several fields we assumed were optional turned out to be legally mandatory under AU peacekeeping protocols. We hardened those as required fields that cannot be left blank on submission.
The 188 templates map to actual operational workflows, not our idea of what those workflows should look like. Template generation pulls from the live event store: an analyst drafting a TACSIT can drag in three recent incidents and the system pre-populates the incident log section, leaving them to write assessment rather than re-type data they already entered elsewhere. Median time to complete a templated report dropped from roughly 45 minutes to under 12 in the initial deployment cohort.
AI Bulletins: The Ethical Constraints We Put on the Model, and Why
Lindela generates AI bulletins, structured automated summaries of the overnight event picture, flagging anomalies and surfacing new entities for analyst review. This is genuinely useful. At the volume of data flowing through the system, no analyst team can read everything. Pattern detection at scale requires automation.
We put explicit constraints on what the model is permitted to generate. We're stating them in public because we think transparency on this is not optional for a system like this.
The individual prediction prohibition is the most straightforward. Predictive profiling of individuals in a conflict environment, even with good intentions and good data, produces false positives. In a peacekeeping context, a false positive is not a customer service complaint. It is information that could lead to the detention, harassment, or harm of a person who has done nothing. The expected cost of that error is high enough that we consider the feature not worth building at any accuracy level currently achievable.
The ethnic and clan profiling prohibition needs more explanation, because the instinct to track community-level conflict patterns is operationally legitimate. East African conflict frequently has a community dimension. Tracking that dimension matters for understanding dynamics. The problem is framing: a system that learns to profile ethnic groups as threat actors will reproduce and amplify a framing, that communities are the unit of threat, that is almost always analytically incorrect and politically dangerous. Conflict framed as "ethnic" is typically driven by specific political actors using community identity as a mobilization tool. Directing analytical attention toward communities rather than those specific actors makes the intelligence worse, not better, while creating a data infrastructure that is a significant misuse risk in the wrong hands.
What the bulletins do: flag statistical anomalies in event frequency or geographic distribution against the 90-day baseline; surface new entities, locations, organizations, incidents, appearing for the first time in the data; generate structured summaries of the OSINT picture that give an analyst a starting point rather than a blank screen. Every bulletin is marked as draft. Every bulletin requires human analyst review and sign-off before it enters the operational intelligence picture. The human is not a rubber stamp, they have override authority, and the training we deliver is explicit that using that authority is expected behavior, not an exceptional event.
The Offline Architecture: Sync at 1,200 Baud
EASF field units operating in remote or contested environments may have sustained connectivity only over HF radio. Satellite uplinks exist but are rationed by bandwidth allocation. There are periods, measured in days, where the only link to higher command is voice. Any system that cannot operate fully offline during those periods is not a system. It is a liability.
We tested our sync protocol over a simulated HF radio connection at 1,200 baud. That is slower than a 1994 dialup modem. It works.
Every field instance runs a full local replica of the relevant operational area's event store. Analysts can read, write, query, and generate reports with zero connectivity. The replica covers 180 days of events for the assigned area of operations plus the full actor and template databases.
Sync uses a binary delta protocol: only changed fields are transmitted, compressed with Zstandard, which achieves better compression ratios than gzip on structured data and decompresses significantly faster. The merge logic is built around conflict-free replicated data types with hybrid logical clock timestamps assigned at creation time, ensuring causal ordering is preserved across merge even when two offline instances have been working the same case independently. When those independent edits conflict, two analysts updating the same incident record from different data sources during a network partition, the system does not silently pick a winner. It surfaces both versions to the next analyst who opens the record, showing provenance for each, and requires explicit resolution. This is operationally slower than automatic merge. It is correct.
Field-level classification is enforced at the replica. Classified content is encrypted at rest using keys derived from the user's authentication credential. A device that is compromised does not expose classified data to an attacker who cannot authenticate as a cleared user. The clearance hierarchy enforced at headquarters is replicated to the field instance: a user's access to specific records is determined by their clearance attributes, not by what data happens to have been synced to their device.
The Hard Question
Intelligence software can be weaponized. This is not a theoretical concern. Commercial surveillance products have a documented history of being repurposed for tracking political opponents, journalists, and civil society. We are building software that manages structured information about conflict actors and events, with access controls, clearance hierarchies, and AI-assisted analysis. In the wrong hands, that is a political repression toolkit.
Our client contracts include explicit prohibited-use clauses. The platform cannot be used for tracking individuals outside of active peacekeeping mandates. It cannot be used for domestic political surveillance. It cannot be used to generate targeting data for kinetic operations without EASF command authorization. Violations trigger contract termination and referral to relevant AU oversight bodies.
Do contracts fully solve this problem? No. We don't pretend otherwise. Contracts are enforced by humans, and humans can be pressured, corrupted, or choose to ignore provisions they find inconvenient. We maintain internal governance processes that include periodic review of how deployed instances are being used, red-team exercises against our own access control model, and an escalation path for staff who observe potential misuse. We have not deployed Lindela to any government without EASF as the primary contracting entity, not because we believe all governments are bad actors, but because the EASF institutional mandate provides a layer of accountability that bilateral government contracts do not.
We think software vendors in the defense and security space have spent too long treating these questions as legal and compliance matters rather than engineering and product matters. The decision about what a system is technically capable of doing is made by engineers, before the lawyers draft the contracts. We made ours explicitly. We think it's worth saying so in public.
Where We Are
Lindela is in active operational deployment with EASF and in evaluation with two additional AU regional mechanisms. The 188 templates are in daily use. The offline sync has been validated across exercise cycles with deliberate connectivity interruptions of up to 72 hours. The AI bulletin has been running in production for eight months. The false-positive rate on anomaly flags is currently 34%, which the J2 staff consider acceptable for a first-read triage tool: the goal is to reduce analyst time on event discovery, not to replace analyst judgment on significance.
Work remaining: better interoperability with UN DPPA data infrastructure; improved maritime domain awareness for the Indian Ocean littoral; calibration of the pastoral conflict correlation models against field-verified historical data. These are not crises. They are the normal shape of a system being used seriously by people who have opinions about it.
We are occasionally asked whether we would build Lindela again knowing what we know now. The answer is yes, with the same ethical constraints and more of them. The alternative is that this software gets built by someone who does not ask these questions. That alternative is not hypothetical: there are vendors already in this space who don't.
If you're working on peace operations technology, conflict data infrastructure, or have relevant experience in African security sector contexts, we're interested in talking. The field is too small and the stakes are too high for unnecessary isolation.