Learn

NLP for intelligence is the application of natural language processing to human-language text so machines can extract entities, relationships, and meaning that analysts then resolve and fuse with other sources into intelligence.
Last updated: October 23, 2026
Why it matters to your mission. Most of what an intelligence enterprise holds is text: reports, cables, message traffic, transcripts, procurement records, and the growing flood of open-source material. A human cannot read it all, and the signal an analyst needs is usually buried in language, not in a tidy database field. Natural language processing is the method that reads that text at machine speed and pulls out the entities, relationships, and meaning inside it. The important caveat, and the reason this page exists, is that NLP produces extracted text, not finished intelligence. Those extractions still have to be resolved to real-world entities and fused with structured and non-text sources before they answer a question. NLP feeds the picture. It is not the whole picture.
NLP for intelligence is the application of natural language processing to human-language text so machines can extract entities, relationships, and meaning that analysts then resolve and fuse with other sources into intelligence. Natural language processing, or NLP, is the branch of artificial intelligence concerned with getting computers to read, interpret, and derive structure from human language. Applied to the intelligence mission, it turns unstructured text into candidate facts: names, places, organizations, events, and the links between them.
The distinction in that definition is deliberate. NLP outputs are intermediate. A model that tags "COL Smith" and "3rd Brigade" in a report has done useful extraction, but it has not told you whether this COL Smith is the same person named in three other documents, or whether the brigade reference matches the one in a structured order-of-battle record. Those are resolution and fusion problems, and they sit downstream of NLP. Treating NLP output as the answer is the most common way text-heavy analysis goes wrong.
The U.S. Government has invested in NLP for exactly this mission for years. NIST runs the evaluations that measure progress on machine translation, speech recognition, information extraction, and summarization, noting that the work helps "facilitate the understanding of large document collections." The research programs behind it are explicit that text extraction serves the analyst rather than replacing them.
Key takeaways
Intelligence NLP is not one model. It is a set of tasks, each of which converts language into a more structured form. The IARPA BETTER program, whose name stands for Better Extraction from Text Towards Enhanced Retrieval, frames the purpose plainly: it "aims to dramatically compress the information discovery cycle for Intelligence Community analysts by designing systems that extract personalized, mission-relevant semantic information from text," specifically "entity and event identification" and "relationships between entities." The following table lists the tasks that matter most for the mission.
| NLP task | What it does | Intelligence use |
|---|---|---|
| Named entity recognition (NER) | Finds and types mentions of people, organizations, locations, equipment, and other entities in text | Pulls the actors and objects out of reports and messages so they can be tracked and linked |
| Relation and event extraction | Identifies how entities are connected and what happened between them | Builds the "who did what to whom" structure that feeds network and activity analysis |
| Coreference resolution | Links multiple mentions of the same entity within or across documents | Collapses "he," "the colonel," and "COL Smith" into one referent before any cross-source work |
| Text classification and triage | Labels documents by topic, priority, sentiment, or relevance | Routes and prioritizes high-volume inflows so analysts read what matters first |
| Summarization | Condenses long or many documents into a short, faithful account | Compresses reporting so an analyst can grasp a corpus without reading every page |
| Machine translation | Renders foreign-language text into the analyst's working language | Makes multilingual open-source and collected text usable by non-native readers |
| Topic and keyword extraction | Surfaces the themes and salient terms across a corpus | Supports discovery and search across large, unfamiliar document sets |
These tasks are the backbone of government NLP evaluations. The NIST Text Analysis Conference (TAC) runs tracks such as Recognizing Ultra Fine-Grained Entities, whose goal is "to extract and corefer mentions of fine-grained entity types in text," and Claim Relation Understanding and Extraction, which exists "to develop and evaluate technologies that extract structured information from a variety of unstructured multilingual multimodal sources." The pattern is consistent: the job of NLP is to turn unstructured language into structured candidate facts.
NLP and entity resolution are sequential, not interchangeable. NLP extracts a mention from text. Entity resolution decides which real-world thing that mention refers to and whether two mentions are the same thing. The first produces candidates. The second produces identity. Confusing them is the single most common error in text-first analysis, because an extracted name is not yet an entity.
An example makes the boundary concrete. NLP reads three reports and extracts "J. Rivera," "Jose Rivera," and "the deputy director." That is good extraction. It is not yet a finding, because nothing has established whether those are one person or three. Resolving that requires comparing attributes, context, and other records, which is the work of entity resolution. Only after resolution can an analyst say there is one Jose Rivera appearing across three documents. The difference between extraction and resolution is explained in more depth in entity extraction vs entity resolution, and it is the hinge on which text-based analysis turns.
| NLP (extraction) | Entity resolution | |
|---|---|---|
| Input | Unstructured text | Extracted mentions plus structured records |
| Output | Candidate mentions: names, relations, events | Resolved entities with a single identity across sources |
| Question answered | "What does this document say?" | "Which real-world thing is this, and have we seen it before?" |
| Failure if skipped | None on its own; it is a first step | Duplicate and fragmented entities; false or missed links |
The takeaway is that NLP is necessary but not sufficient. It is the extraction stage. Resolution is the stage that gives the extractions an identity a system can reason over.
Open-source intelligence is where NLP earns its keep, because open-source is overwhelmingly text and the volume is beyond human reading. The IC OSINT Strategy for 2024-2026, released by ODNI and CIA, defines OSINT as "intelligence derived exclusively from publicly or commercially available information that addresses specific intelligence priorities, requirements, or gaps," and calls it "the INT of First Resort." It commits the community to "develop innovative technologies to collect and derive insight from open source data." NLP is the technology that derives that insight from text at scale.
In an OSINT workflow, NLP does the first pass that no human has time to do. It classifies and triages inbound material so analysts see the relevant fraction first. It translates foreign-language sources so a monolingual analyst can work them. It extracts the entities, relationships, and events that become leads. The DARPA LORELEI program was built precisely for the hard version of this, processing "topics, entities, relations and sentiment" in low-resource languages where off-the-shelf NLP is insufficient, under severe time pressure. The common thread across OSINT and the broader discipline of open-source intelligence (OSINT) is that NLP makes the unreadable readable, but it hands off candidates, not conclusions.
The same caveat applies with extra force in OSINT. Open-source text is noisy, contradictory, and sometimes deliberately deceptive. Extracting a claim from an open source does not make it true or even relevant. The extraction has to be corroborated against other sources, which is a fusion problem, not an NLP problem.
NLP has real and well-understood limits, and an honest intelligence capability designs around them rather than hiding them. The first limit is that extraction is not truth. A model can confidently tag an entity or a relation that is wrong, ambiguous, or taken out of context. Output quality also degrades on the domains, jargon, and languages that matter most to the mission, which is a known failure mode in operational text and the reason government programs invest in domain and low-resource language work.
The second limit is the one this page keeps returning to: NLP produces disconnected mentions. A corpus run through even an excellent extractor yields thousands of tagged names, places, and relations with no inherent identity and no connection to structured holdings. Nothing in that output tells you that two names are the same person, that a text-mentioned unit matches a record in a system of record, or that an event corroborates a separate report. Those are resolution and fusion tasks that live downstream of the model. An analyst handed raw extractions still has to do the hardest part by hand unless the infrastructure does it for them.
The third limit is traceability. Intelligence has to be defensible, which means every extracted fact must trace back to the source document and the model decision that produced it. An extraction pipeline that cannot show its provenance produces assertions an analyst cannot stand behind. That is why extraction has to be governed and traceable, not just accurate on average.
NLP needs fusion because a single text source almost never answers an intelligence question on its own. The answer usually lives in the combination: a name in a report, a record in a structured database, an image, a signal, a prior piece of reporting. NLP can extract the text component, but turning that component into intelligence means resolving it to an entity and fusing it with everything else known about that entity. Fusion is where extracted text becomes understanding.
This is why text-first approaches hit a ceiling. A capability built primarily around extracting and searching text treats the text as the destination. In practice the text is a starting point. The extracted entities and relationships have to be reconciled with structured records and non-text sources, and the contradictions between them surfaced rather than averaged away. That reconciliation across types of data is the discipline of multi-INT fusion, and it is what separates a text-analytics tool from an intelligence capability. The underlying reason the two have to work together is the nature of the inputs themselves, which is why the relationship between structured and unstructured data for AI sits at the center of the problem: NLP handles the unstructured side, but the answer requires joining it to the structured side.
The honest framing is a sequence. Extract with NLP. Resolve the extractions to entities. Fuse the resolved entities with structured and non-text sources. Preserve provenance at every step so the result is defensible. Skip any stage and the output is a pile of mentions, not intelligence.
Torch.AI does not position NLP as the product, and this page is not a claim that extraction alone is the answer. NLP is a method, and a text-first approach that stops at extraction and search is exactly the pattern Torch.AI is built to move past. What Torch.AI builds is the government-owned reasoning infrastructure that takes NLP output through the stages where it actually becomes intelligence: resolving extracted mentions to entities, fusing them with structured and non-text sources, and keeping every step traceable to its source.
The products map to that sequence. NEXUS applies semantic representation so unstructured text becomes something a system can correlate rather than merely search, which is where raw NLP extraction is refined into meaning. HALO fuses resolved entities and relationships into a graph an analyst can inspect, which is the resolution-and-fusion work that text extraction alone cannot do. ORCUS provides the data-availability layer that connects to the source systems and preserves provenance, so an extracted fact traces back to the document it came from. Because this runs as a system of reason on top of existing systems of record, the authoritative sources stay intact, and in a government-owned deployment the customer keeps control of the layer where extracted text becomes understanding. You can see how this is packaged on the Torch.AI software page.
For evaluators, the distinction is the point. If your problem is that text extraction gives you mentions you still have to resolve and fuse by hand, that gap is a reasoning infrastructure problem, and it is the one this infrastructure is built for. The related challenge of turning raw documents into usable structured input is covered in unstructured document processing (DOMEX). Request a technical walkthrough and we will run NLP extraction through resolution and fusion against a representative slice of your own multi-source data, with provenance traced end to end.
NLP models are a commodity. The gap is everything downstream of extraction. If you are evaluating a capability that uses NLP for intelligence, require:
Evaluating a capability? Bring these six requirements to a scoping call and we will walk each one against your environment: request a technical walkthrough.
The core tasks are named entity recognition, relation and event extraction, coreference resolution, text classification and triage, summarization, machine translation, and topic extraction. Each converts unstructured language into structured candidate facts. Government NLP evaluations run by NIST, and research programs such as IARPA BETTER, center on entity, event, and relationship extraction from text.
NLP extracts mentions from text, such as names, relations, and events. Entity resolution decides which real-world entity each mention refers to and whether two mentions are the same thing. NLP produces candidates; resolution produces identity. They are sequential stages, and extraction without resolution yields duplicate, fragmented entities rather than a usable picture.
Open-source material is mostly text at a volume no human can read, so NLP does the first pass: triaging and classifying inbound material, translating foreign-language sources, and extracting entities, relationships, and events as leads. The IC OSINT Strategy calls for technologies to derive insight from open-source data, and NLP is that technology, but it produces candidates that still require corroboration.
NLP extraction is not truth: models can tag entities or relations that are wrong or out of context, and quality drops on specialized domains and low-resource languages. NLP also produces disconnected mentions with no inherent identity or connection to structured holdings. Resolving and fusing those mentions, and preserving provenance, are separate tasks that live downstream of the model.
Because a single text source rarely answers an intelligence question on its own. NLP extracts the text component, but the answer usually lives in the combination of that text with structured records, imagery, signals, and prior reporting. Fusing resolved entities across sources, and surfacing contradictions, is what turns extracted text into intelligence. Extraction alone produces mentions, not understanding.
They overlap. Text analytics is the broader practice of deriving structure and insight from text, and NLP provides the underlying methods such as entity and relation extraction, classification, and summarization. For intelligence, both share the same limit: the extracted output is a starting point that must be resolved to entities and fused with other sources to become usable.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the text you hold. We will scope NLP for intelligence through resolution and fusion against your multi-source data. No search demo. Your documents. Real work.