Each of these has mature tooling. What most units lack is the layer that puts them together – and the practical consequence is that the connective work happens in an analyst’s head, or in a spreadsheet, and is neither reproducible nor auditable. Individual pieces of this stack – CDR analysis, link analysis, OSINT – are covered elsewhere on this site. This piece is about the layer that connects them.
Investigation data fusion is the name for that missing layer.
Investigation data fusion: a working definition
Data fusion is the process of combining information from multiple heterogeneous sources into a single, coherent analytical representation, in which entities are resolved across sources and every assertion retains its provenance.
Three parts of that definition carry the weight.
Heterogeneous sources. Not multiple databases of the same kind, but structurally different data: tabular call records, unstructured documents, video, audio, geospatial traces.
Entities resolved across sources. The person in the bank statement, the subscriber in the call record, the face in the footage and the voice in the intercept are recognised as one entity, or explicitly recorded as an unresolved hypothesis.
Provenance retained. Every fact in the fused picture can be traced to the source it came from, the authority under which it was obtained, and the analyst who entered it.
Systems that do the first two without the third produce something that looks like intelligence and cannot be defended.
Why fusion, specifically
The argument for fusion is not that it is technologically interesting. It is that the questions investigations turn on are inherently cross-modal.
A financial trail shows funds moving to an account. A communication record shows contact between two numbers. Video shows a person at an ATM. Independently, each is weak. Fused – the account holder’s number in contact with the target immediately before a withdrawal, and a person at that ATM at that time whose appearance is consistent with a subject seen elsewhere – the picture is materially different.
Analysts have always done this manually. What changes at scale is feasibility. Cross-referencing four modalities across ninety days and six targets is not a task human working memory performs reliably, and the errors it produces are silent.
What fusion requires
Ingestion that handles local reality. Multi-operator call record formats, multiple bank statement layouts, scanned documents, regional-language text, proprietary video exports. In Indian conditions this is the majority of the engineering effort, and platforms built elsewhere routinely underestimate it.
Entity resolution with visible decisions. Transliteration variance, informal addresses, and the absence of a usable common identifier make this hard. Every merge must be visible, attributable and reversible, because over-merging creates false networks and under-merging hides real ones – both silently.
A common temporal and spatial frame. Sources record time differently and locate things at wildly different resolutions. Fusion must normalise time and must represent spatial uncertainty honestly – a cell sector as a coverage area, not a pin.
Provenance and confidence grading. Source, authority, analyst, date, confidence. On every assertion.
Governance built in. Access aligned to case assignment, purpose limitation, retention rules, and query-level audit logging.
The risk that comes with the capability
Fusion increases analytical power by combining data that was collected separately, often under separate authorities and for separate purposes. That is precisely what makes it useful and precisely what makes it sensitive.
A responsible deployment treats several things as structural rather than optional. Each dataset carries the legal basis under which it was obtained, and that basis follows the data. Access is granted by case assignment rather than by rank. Every query is logged against a case authority and the logs are periodically audited. Retention periods are defined per dataset and enforced. And the system is deployed inside the agency’s own infrastructure, because fused investigative data is among the most sensitive data an institution holds.
Units that install these controls at the outset find them unremarkable. Units that defer them find them impossible to retrofit, and typically discover this during an oversight review.
What fusion does not do
It does not identify people. It surfaces candidate connections that an investigator must verify against the underlying evidence.
It does not resolve conflicting evidence. It makes conflicts visible, which is more useful.
It does not substitute for analytical training. The characteristic failure modes – treating structural prominence as importance, reading absence as evidence, allowing a plausible hypothesis to filter subsequent interpretation – are analytical failures that no platform prevents.
Where to start
The pattern that works is narrow and deep rather than broad and shallow. Choose one case type with a recurring shape – organised financial fraud and serial property offences are both good candidates – and build reliable fusion across the two or three modalities that case type actually depends on.
That produces demonstrable value within a quarter, exposes the real data quality problems early, and builds the governance habits on a small footprint where they are cheap to establish.
The alternative – procuring a general fusion capability and discovering the ingestion problems afterwards – is how most of these programmes stall. Our overview of the crime analysis software stack covers where fusion sits relative to the other layers, and pi-scout is built around exactly this narrow-and-deep deployment pattern.
