.svg){kind=icon}
Entity resolution for intelligence analysis is the process of determining when records from many separate, multi-source intelligence systems refer to the same real-world person, organization, location, or object, then linking them into one provenance-preserving entity so analysts reason over a single picture.
Also called identity resolution, record linkage, or entity disambiguation.
Every downstream judgment inherits whichever fragments you failed to connect: the network chart, the targeting package, the model. Get the match wrong and the error propagates silently. Getting the match right first is what makes everything after it defensible.
This is also the step that turns systems of record into a system of reason: understanding built on top of the authoritative data, not a replacement for it. In an intelligence context it is the foundation of all-source, multi-INT data fusion. You cannot fuse what you cannot first match.
Key takeaways
Intelligence data is fragmented by design. The same person, unit, vessel, or facility shows up across signals, human, open-source, and geospatial reporting as different records, under aliases and transliterations, with partial identifiers and conflicting details. No single system holds the whole picture, and none was built to line up cleanly with the others. Entity resolution is the point where those scattered systems are finally reconciled into one entity an analyst can reason over.
Consider a single vessel that appears under three transliterated names across SIGINT collection, an OSINT shipping registry, and a GEOINT track. Treated as three objects, it inflates the order of battle (the count and disposition of adversary forces) and splits its own pattern of life (where a subject is, when it is active, and what it interacts with). Resolved as one, it becomes a single track an analyst can act on. That is the difference entity resolution makes at the record level.
That fragmentation carries straight into analysis. Duplicate entities inflate a network and hide its real center of gravity, while missed matches quietly sever the connections that mattered most. Analysts spend hours reconciling records by hand, and anything built on the data, including a knowledge graph or a downstream model, inherits those errors and amplifies them.
The Department of Defense has made this a program-level priority. Its Combined Joint All-Domain Command and Control (CJADC2) effort and the Chief Digital and Artificial Intelligence Office's Open DAGIR initiative (Open Data and Applications Government-owned Interoperable Repositories) both turn on combining data from many sources into a common, decision-ready picture while the government retains ownership of its data (see the CDAO Open DAGIR fact sheet, 2024). Independent oversight has flagged how hard that integration is in practice (see the U.S. Government Accountability Office, GAO-25-106454, Defense Command and Control, 2025). Entity resolution is the step where that fragmentation is actually reconciled.
Entity resolution turns those fragments into one entity, one network, with a clear line back to every source. It is a precondition for the clarity a decision depends on: a briefable, defensible network picture rather than a pile of unmatched leads.
Entity resolution is a pipeline, not a single algorithm. In an intelligence setting the stages are:
Worked through the vessel example: ingest pulls the SIGINT, OSINT, and GEOINT records into a common form; candidate generation flags the three as possible matches on partial name and location overlap; matching scores the transliterated names, co-located tracks, and timing; clustering groups them as one vessel with a confidence score; an analyst confirms the ambiguous OSINT tie; and the resolved vessel keeps links back to all three originals, each with its own classification intact.
One distinction is load-bearing: matching is not merging. Sound entity resolution links records and preserves the originals with their classification and confidence intact. It reasons on top of the authoritative sources; it never overwrites them.
Entity resolution is only as good as what it can see. In a multi-INT setting it draws on four kinds of input, and the point is that no single one is sufficient on its own:
Each source carries partial identifiers, its own spelling conventions, and its own classification. Entity resolution has to compare across all of them without forcing them into one schema, and without pooling data that classification or releasability rules say cannot be combined. The richer and more varied the inputs, the more a match can be corroborated, and the more provenance an analyst has to inspect when they challenge it.
The vessel example resolves one object. Most mission questions turn on a person and the network around them, where the payoff of resolution compounds. Consider building a pattern of life on a single individual of interest from feeds that never reference each other.
A HUMINT report names a mid-level facilitator by a local spelling and a nickname. A SIGINT selector ties a phone number to a slightly different transliteration of the same name. An OSINT pull surfaces a business registration under a third spelling, listing an address. A GEOINT track shows a vehicle at that address on the same nights the phone was active. Financial reporting flags a company at the same address moving payments to a fourth name.
Handled as separate records, this is five weak, disconnected leads, each easy to dismiss on its own. Entity resolution does the connective work: it proposes that the HUMINT nickname, the SIGINT selector, and the OSINT registration describe one person; it links that person to the address, the vehicle pattern, and the payment flow; and it flags the fourth name as a probable alias for analyst review rather than asserting it. What emerges is a single resolved entity assembled at machine speed from fragments no analyst had time to correlate by hand, feeding directly into a knowledge graph and graph-based fusion. It shows where the individual is, when they are active, and who they transact with. Every element in that picture still traces back to the report it came from, with its original classification and confidence, so the conclusion can be briefed, challenged, and defended.
The failure mode is just as instructive. Resolve too aggressively and you fuse two different people into one entity, and the pattern of life becomes fiction. Resolve too timidly and the five leads stay disconnected, and the network is never seen. That tension, between missing a match and manufacturing one, is why confidence scoring, provenance, and analyst adjudication are not optional extras but the core of doing this responsibly.
Bottom line: traditional entity resolution assumes a cooperative subject and clean, structured, owned data; multi-INT resolution assumes an adversarial subject and heterogeneous, classified, often unowned data. The table below is the record-level contrast; the Commercial vs. Government-Owned table further down covers the acquisition-level contrast (ownership, portability, where it runs).
Most entity resolution was designed for a friendlier problem than the mission presents: clean, structured, cooperatively supplied records where the subject wants to be identified. Multi-INT resolution inverts almost every assumption. The contrast is worth making explicit, because tools built for the first column routinely underperform when pointed at the second.
Record-level contrast
| Dimension | Traditional entity resolution | Multi-INT entity resolution |
|---|---|---|
| Input data | Structured records with defined fields | Structured records, free text, signals, and imagery-derived data with no shared schema |
| The subject | Cooperative; wants to be matched | Adversarial; actively works to avoid resolution |
| Names and identifiers | Stable, single-alphabet, often verified | Aliases, transliterations, and deliberate deception across alphabets |
| Data ownership | Owned or licensed, cleanly governed | Denied-area and third-party reporting, incomplete and hard to verify |
| Access model | One pooled dataset | Classification, compartments, and releasability constrain what can be compared |
| Operating environment | Connected data center or cloud | From the enterprise to the disconnected, degraded tactical edge |
| Acceptable output | A merged golden record | A linked entity with provenance, confidence, and analyst adjudication |
The takeaway is not that traditional techniques are wrong; matching statistics and clustering carry over. It is that a mission-grade capability has to add what the commercial lane never needed: adversarial name handling, multi-INT heterogeneity, classification awareness, and a traceable line back to every source.
These terms are often used interchangeably. In practice they name different steps. The table below separates them so each can be cited on its own.
| Term | What it does | Relationship to entity resolution |
|---|---|---|
| Entity extraction, or named entity recognition (NER) | Pulls entity mentions out of text; finds who and what is named | An input to resolution. Extraction finds the mentions; resolution decides which mentions are the same real entity |
| Record linkage | The statistical discipline of matching structured records | A narrower technique inside resolution. Entity resolution is the broader operational capability: multi-source, structured and unstructured, at scale, with provenance and analyst review |
| Master data management (MDM) | Builds a single golden record for commercial master data such as customers and products, on cooperative, owned data | Entity resolution is a core technique inside MDM, but intelligence entity resolution runs on adversarial, multi-INT, classified data where there is no cooperative master and the subject is actively working not to be resolved |
Most entity resolution tools were built for commercial fraud, compliance, or customer data, then pointed at defense problems. For a mission, what separates them is ownership and where they can run. Where the Traditional vs. Multi-INT table above contrasts the record-level problem, this table contrasts the acquisition decision: the traditional commercial approach versus government-owned reasoning infrastructure across the considerations that decide a mission.
Acquisition-level contrast
| Consideration | Typical commercial platform | Government-owned reasoning infrastructure |
|---|---|---|
| Control of the resolved data and logic | Held in the vendor's proprietary environment | Customer keeps control of the reasoning layer |
| Relationship to existing systems | Often a new platform to migrate onto | Complements systems of record; no rip-and-replace |
| Where it can run | Frequently cloud-only or managed service | Enterprise to disconnected tactical edge |
| Data it works on | Usually tuned for clean structured records | All-source, multi-INT, structured and unstructured |
| Portability of the resolved entities | Locked to the vendor's semantic model | Portable across systems; feeds downstream reasoning |
| Provenance and auditability | Varies; scoring is often opaque | Every match traces to source, analyst-inspectable |
Government-owned does not mean the government builds everything from scratch, nor that the government owns the vendor's underlying intellectual property. It means the customer keeps control of the mission layer where data, context, and decision-support come together, and can inspect, govern, and evolve it, rather than working inside a vendor's proprietary semantic model. Whether a specific deployment is government-owned (GOTS) or commercial (COTS) depends on the system the customer installs and purchases; the point here is that the government-owned model is available, and it is the one to evaluate for when ownership and control matter to the mission.
The comparison above explains why ownership and portability matter; the checklist below is what to actually require in an evaluation.
Evaluating a capability? The seven requirements above are the backbone of a defense entity resolution evaluation you can score vendors against. Bring the seven requirements to a scoping call and we will walk each one against your environment: request a technical walkthrough.
Torch.AI builds reasoning infrastructure the customer can own and govern, offered as a government-owned (GOTS) deployment when a mission requires it. The reasoning layer connects to mission data where it lives and resolves entities across fragmented, multi-source systems while preserving provenance, matching the records that describe the same real-world entity without displacing the systems of record they came from. It then links those resolved entities through graph-based fusion into relationships an analyst can trust and trace. The result is a briefable, defensible network picture that turns fragmented, multi-source data into coherent understanding at machine speed. You can see how this is packaged as a capability on the Torch.AI software page.
In a government-owned deployment, the customer keeps control of the layer where data becomes understanding: they can inspect it, govern it, and evolve it. And because it reasons on top of and around existing systems of record rather than replacing them, the authoritative sources stay intact and interoperable, not locked inside a proprietary semantic model. This is the systems of record versus systems of reason distinction at the center of Torch.AI's approach: the reasoning layer acts as a system of reason on top of the customer's existing systems of record.
Torch.AI's approach is built for the conditions this page describes: all-source, multi-INT data; classification-aware resolution; analyst-in-the-loop adjudication; and operation from the enterprise to the disconnected tactical edge, with every resolved entity traceable back to its sources.
For evaluators scoping a capability, see how Torch.AI delivers entity resolution and graph-based fusion on multi-INT data, deployable government-owned, on the software page, or request a technical walkthrough and we will run it against a sample of your multi-INT data, with provenance traced end to end.
Is entity resolution the same as entity extraction? No. Entity extraction (NER) finds and pulls entity mentions out of text; entity resolution decides which of those mentions refer to the same real-world entity. See entity extraction (NER) in the terms table.
What is the difference between entity resolution and record linkage? Record linkage is the statistical method for matching structured records; entity resolution is the broader operational capability across many sources, structured and unstructured, at scale, with provenance and analyst review.
What is the difference between entity resolution and master data management (MDM)? MDM builds a single golden record for cooperative, owned commercial data, whereas intelligence entity resolution runs on adversarial, multi-INT, classified data with no cooperative master and produces a linked, provenance-preserving entity rather than an overwritten golden record.
Can entity resolution work on unstructured, multi-INT data? Yes, if it is built for it. Intelligence entity resolution has to handle free text and heterogeneous multi-INT reporting, aliases and transliteration, and classification constraints, not only clean structured records.
How does entity resolution work with an LLM? A large language model helps at the reading and matching stages, extracting entity mentions from free text and judging whether two differently worded references describe the same entity, but it does not replace the discipline. In an intelligence setting an LLM's proposals still have to carry a confidence score, preserve provenance back to every source record, respect classification, and route ambiguous matches to an analyst. The model is one input to a governed pipeline, not the resolution itself.
How is entity resolution measured? It is measured against a ground-truth set of known matches and non-matches, using precision (of the pairs it linked, how many were correct) and recall (of the true matches, how many it found). The two trade off: pushing recall higher risks false links, and pushing precision higher risks missed ones. In a mission context the more important measure is whether every match is traceable and adjudicable, because an unexplained match cannot be defended in a briefing regardless of its score. Expected accuracy depends entirely on the data and the threshold, so a defensible evaluation runs against your own mission dataset rather than a vendor's benchmark.
What does government-owned entity resolution mean? It is a deployment and ownership model (GOTS) in which the customer keeps control of the resolved data, the model, and the match logic, and can run them in classified or disconnected environments independently of any single vendor, rather than working inside a vendor-hosted proprietary platform. The same capability can also be delivered commercially (COTS); which one applies depends on the system the customer installs and purchases.
Does entity resolution merge or overwrite source records? It should not. Sound entity resolution links records and preserves the originals with their classification and confidence, so any match can be inspected, explained, and reversed. It reasons on top of the systems of record; it does not replace them.