.svg){kind=icon}
Learn
Entity extraction, or named entity recognition, pulls entity mentions out of unstructured text; entity resolution decides which of those mentions, across many sources, refer to the same real-world entity and links them into one provenance-preserving record.
Last updated: October 18, 2026
Why it matters to your mission. Most of the intelligence picture is buried in prose, and a name pulled from a report is worthless until you know whether it is a new person or one you already track. Entity extraction finds the names, places, and objects a document mentions; entity resolution decides which of those mentions, across every system you hold, are the same real-world entity and links them with a trace back to source. The outcome is one briefable, defensible picture instead of thousands of disconnected mentions, assembled at machine speed with reasoning an analyst can inspect.
Entity extraction, or named entity recognition, pulls entity mentions out of unstructured text; entity resolution decides which of those mentions, across many sources, refer to the same real-world entity and links them into one provenance-preserving record. Extraction finds the mentions; resolution decides which mentions are the same entity.
Put plainly: extraction is the reading step and resolution is the reasoning step. Extraction answers "what entities does this document name?" Entity resolution answers "across everything we hold, which of those named mentions are actually the same person, unit, vessel, or place, and how confident are we, with a trace back to every source?" One is a precondition for the other. You cannot resolve entities you never pulled out of the text, and extraction on its own leaves you with a pile of unmatched names.
No. They are consecutive steps in the same pipeline, not synonyms. Confusing them means buying half a capability.
Entity extraction, commonly called named entity recognition (NER), is the natural-language task of locating spans of text that name an entity and labeling each by type: a person, an organization, a location, a date, a vessel, a weapon system. It operates on one document at a time. Its output is a set of tagged mentions. A single report that names "Abu Khalid," "the Al-Noor Trading Company," and "Port Sudan" produces three typed mentions. Extraction does not know, and does not try to decide, whether "Abu Khalid" here is the same man named in a report filed last month under a different spelling.
Entity resolution is that deciding step. It takes mentions, from extraction and from structured systems, and determines which ones point to the same real-world entity, then links them into a single entity that preserves a line back to every contributing source. It compares names across aliases and transliterations, weighs partial identifiers, scores the match, routes the ambiguous cases to an analyst, and keeps the originals intact. Extraction gives you mentions; resolution gives you entities.
Hold them apart this way: extraction turns prose into structured mentions; resolution turns those mentions, together with the rest of your data, into one trustworthy picture.
The two work as a sequence, and the quality of each stage sets a ceiling on the next.
Miss a mention at extraction and resolution never gets the chance to connect it. Over-extract, or mislabel a type, and resolution wastes effort on noise or links the wrong things. In an intelligence setting this is why extraction is not a solved commodity: adversarial names, transliteration, and prose that hides identity make the reading step hard before the matching step even begins.
The table separates the two so each can be evaluated on its own terms. Extraction is a text-processing task on one document; resolution is a cross-source capability over everything you hold.
| Dimension | Entity extraction (NER) | Entity resolution |
|---|---|---|
| What it is | Finding and typing entity mentions in text | Deciding which mentions and records are the same real-world entity |
| Core question | What entities does this document name? | Across everything we hold, which mentions are the same entity? |
| Scope | One document at a time | Many sources at once, structured and unstructured |
| Input | Unstructured text | Extracted mentions plus structured records, signals, and imagery-derived data |
| Output | Typed mentions (person, org, location, object) | A linked entity with confidence and provenance, originals preserved |
| Deals with aliases | No; it reports the surface mention as written | Yes; it reconciles aliases, transliterations, and partial identifiers |
| Confidence | Per-mention label confidence | Per-match confidence an analyst can weigh |
| Human role | Review of extraction errors | Adjudication of ambiguous matches |
| Position in the pipeline | The reading step; an input to resolution | The reasoning step that consumes extraction output |
Neither step is optional. Extraction without resolution leaves mentions disconnected; resolution without good extraction never sees most of what the prose contained.
You need entity extraction whenever the information you care about is locked in unstructured text and you want it as structured, typed mentions you can query, count, or route. If the problem is "turn this corpus of reporting into a list of who and what is named," extraction is the task.
You need entity resolution the moment those mentions have to become entities. If the same person appears under three spellings across five feeds, if duplicate records are inflating a network, if a new report has to be connected to an entity you already track, extraction alone cannot answer it. Resolution is what collapses many mentions into one entity and keeps the connections, and the disconnections, defensible.
Defense and intelligence work needs both, run as one pipeline. The Department of Defense has made integrating data across many separate systems a program-level priority through its Combined Joint All-Domain Command and Control (CJADC2) effort, and independent oversight has documented how manual that integration still is: analysts "collect, assess, and package the data by manually entering and transferring them into yet another system," the "swivel chair" analysis CJADC2 aims to replace with "a data integration layer" that "effectively connects existing federated data across multiple systems and mission areas" (U.S. Government Accountability Office, GAO-25-106454, Defense Command and Control, 2025). Extraction turns the prose in those systems into mentions; resolution connects the mentions across the systems. Buying one without the other leaves the manual gap in place.
Torch.AI builds government-owned reasoning infrastructure the customer can own and govern. Within it, NEXUS makes data meaningful: it extracts entities from unstructured text and gives multi-source records a common semantic representation, which is the reading step that turns prose into typed, comparable mentions. HALO then performs entity resolution and graph-based fusion, deciding which mentions and records describe the same real-world entity across fragmented, multi-source systems, attaching confidence, and preserving a trace back to every source so the match can be inspected and reversed. Extraction and resolution run as one pipeline rather than two disconnected tools.
This reasoning layer complements existing systems of record rather than replacing them, so authoritative data stays intact and interoperable instead of locked inside a proprietary model. Whether a specific deployment is government-owned (GOTS) or commercial (COTS) depends on the system the customer installs and purchases; the point is that the government-owned model is available to evaluate when ownership and control matter to the mission. You can see how this is packaged as a capability on the Torch.AI software page. For the full capability, see entity resolution for intelligence analysis.
If you are evaluating a capability that claims to go from raw text to resolved entities, require the following:
Scoping a capability? Bring these requirements to a call and we will walk each one against your environment and run it on a sample of your multi-source data, from raw text to resolved entity, with provenance traced end to end: request a technical walkthrough.
No. Entity extraction, or named entity recognition, finds and types entity mentions inside unstructured text, one document at a time. Entity resolution decides which of those mentions, across many sources, refer to the same real-world entity and links them into one provenance-preserving record. Extraction is the reading step; resolution is the reasoning step that consumes its output.
Extraction reads text and produces typed entity mentions. Those mentions are normalized, compared against each other and against structured records through candidate generation and scored matching, and the ones that describe the same entity are clustered into a single resolved entity with a confidence score and a trace back to every source. Extraction sets the ceiling: a mention that was never extracted cannot be resolved.
Use extraction when you need to turn unstructured text into structured, typed mentions you can query or count. Use resolution when those mentions have to become entities, when the same subject appears under different spellings across feeds, when duplicates inflate a network, or when a new report must be connected to an entity you already track. Defense and intelligence work needs both, run as one pipeline.
Named entity recognition is the natural-language task of locating spans of text that name an entity and labeling each by type, such as person, organization, location, date, or object. It is the common technical term for entity extraction and is the input step that precedes entity resolution.
No. Extraction reports the surface mention as written, including whatever spelling or alias the document used. Reconciling aliases, transliterations, and partial identifiers across sources is the job of entity resolution, which weighs them, scores the match, and routes ambiguous cases to an analyst.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
