Detecting Anomalies in Conflict-Event Time Series with Isolation Forest

Why conflict-event data is a good fit for anomaly detection

Open datasets that catalogue discrete real-world events — armed conflict incidents, protests, aviation movements, ship positions, or news mentions — share a common statistical shape. Most locations and time windows show a low, fairly stable baseline rate of activity, punctuated occasionally by sharp, short-lived spikes. That shape is exactly what unsupervised anomaly-detection algorithms are designed to find: they don't need labelled examples of "anomalous" events beforehand, only a model of what "normal" density and clustering look like, learned directly from the data.

The Armed Conflict Location & Event Data Project (ACLED) is a widely used example of this kind of dataset. It records individual events — geocoded to a specific location and date, tagged with an event type (battles, protests, violence against civilians, and so on), an actor field, and often a fatality estimate. Structuring analysis around a table like this — one row per event, with numeric, categorical, and geospatial columns — makes it straightforward to engineer features such as "events per region per day" or "7-day rolling event count" that feed into a detection model.

How Isolation Forest actually works

Isolation Forest, introduced by Liu, Ting and Zhou in 2008, takes a different approach to outlier detection than distance- or density-based methods like k-nearest-neighbours or local outlier factor. Instead of modelling what normal points look like, it tries to isolate individual points by recursive random partitioning: it repeatedly picks a random feature and a random split value within that feature's range, dividing the data into two groups, and repeats this recursively until every point sits alone in its own partition.

The key insight is that anomalies — points that are rare or sit far from the bulk of the data — tend to get isolated in very few splits, because random partitions are likely to separate them from the crowd early. Normal points, packed tightly together in dense regions, require many more splits before they end up alone. The algorithm builds an ensemble of such random trees (an "isolation forest") and averages the path length needed to isolate each point across all trees. A short average path length translates into a high anomaly score.

This makes Isolation Forest computationally cheap — roughly linear in the number of points — and it scales well to the kind of multi-thousand-row daily event tables that a conflict-monitoring or aviation-tracking pipeline accumulates over time, without needing to compute pairwise distances between every observation.

Turning raw events into a feature table

Anomaly detection rarely runs on raw event logs directly. The first engineering step is usually aggregation: events are grouped into fixed windows (daily or weekly) per region, and a set of numeric features is computed for each window — total event count, count broken down by event type, a rolling mean and standard deviation over the preceding N windows, and the day-over-day percentage change. A common configuration parameter here is contamination, the expected proportion of the dataset that is anomalous; setting it to something like 0.1 tells the model to treat roughly the top 10% most isolable points as outliers, which in turn sets the decision threshold on the anomaly score.

Because event counts are heavily right-skewed (many quiet days, occasional extreme spikes), it's common to log-transform the count features before fitting the model, and to compute features per region rather than pooling the entire dataset together — a spike that would be unremarkable in a historically high-activity region could be a strong anomaly in one that is normally quiet. This kind of local, region-relative normalisation is one of the more important design choices in the whole pipeline; a global threshold applied uniformly across very different baselines tends to either miss meaningful local anomalies or drown in false positives from naturally busy areas.

PyOD: a common toolkit for outlier detection

PyOD is a Python library that provides a consistent scikit-learn-style interface (fit, predict, decision_function) across dozens of outlier-detection algorithms, from classic statistical methods like Z-score and Elliptic Envelope, through proximity-based methods like Local Outlier Factor and k-NN, to ensemble methods like Isolation Forest and more recent deep-learning-based autoencoder approaches. Having a shared interface makes it practical to run several detectors over the same feature table and compare their outputs, rather than committing to a single algorithm's assumptions.

This matters because different detectors are sensitive to different kinds of anomaly. Isolation Forest is good at catching global outliers — points that are extreme relative to the whole dataset. Local Outlier Factor is better suited to local anomalies, where a point is unusual only relative to its immediate neighbourhood even though it wouldn't stand out globally. In a geospatial event dataset, that distinction maps naturally onto "an unprecedented country-wide spike" versus "an unusual cluster in one small district that's still small in absolute national terms." Running both and comparing flagged points is a standard sanity check before treating any single score as ground truth.

From an anomaly score to something a human can review

An anomaly score on its own is not a conclusion — it's a prioritisation signal. A defensible pipeline treats the model's output as a way to triage a much larger stream of events down to a shortlist worth a human analyst's attention, not as an automated verdict. Good practice includes logging the specific features that drove a high score (was it the raw count, the rate of change, or an unusual event-type mix?), keeping the underlying event records linked to each flagged window so an analyst can drill down to source rows, and tracking false-positive rates over time so the contamination parameter and feature set can be tuned.

It's also worth being explicit about what statistical anomaly detection can and cannot tell you. A high anomaly score means "this pattern is statistically unusual relative to recent history in this dataset," nothing more. It does not, by itself, establish cause, severity, or reliability of the underlying reporting — open event datasets aggregate reports from many secondary sources with varying coverage and delay, so a spike can reflect a genuine change in events, a change in reporting density, or a data-collection artefact. Treating the model as a filter that routes interesting time windows toward closer, source-level investigation is the appropriate framing.

Combining time-series and geospatial signals

Because each event carries a latitude/longitude pair as well as a timestamp, anomaly detection can be extended into the spatial dimension using clustering techniques like DBSCAN (density-based spatial clustering), which groups events that are close together in space and time into clusters while explicitly labelling sparse, isolated points as noise. Overlaying a temporal anomaly score with a spatial cluster density map gives a more complete picture than either signal alone: a time-series spike concentrated in a single tight geographic cluster reads very differently from the same aggregate spike spread thinly across a wide area, even though a purely count-based feature table might score both equally.