.svg){kind=icon}
Learn
TCPED (tasking, collection, processing, exploitation, dissemination) is the five-step ISR workflow that turns a collection requirement into finished intelligence: tasking a sensor, collecting data, processing it into a readable form, exploiting it for meaning, and disseminating the result to decision-makers.
Last updated: October 23, 2026
Why it matters to your mission. A sensor that collects an image, intercept, or signal has produced nothing a commander can act on until that material is processed, exploited, and delivered in time. TCPED is the workflow that governs that whole path, from the decision to task a sensor to the moment finished intelligence reaches the decision-maker. Most of the delay does not live in the sensor; it lives in the middle of the cycle, where fragmented, multi-source data has to be turned into meaning faster than the decision window closes. A healthy TCPED cycle puts usable intelligence in the right hands while there is still time to use it.
TCPED (tasking, collection, processing, exploitation, dissemination) is the five-step ISR workflow that turns a collection requirement into finished intelligence: tasking a sensor, collecting data, processing it into a readable form, exploiting it for meaning, and disseminating the result to decision-makers. The acronym names the full path a piece of intelligence travels, from the moment a requirement is assigned to a collection asset to the moment a product reaches the person who needs it.
TCPED is the intelligence, surveillance, and reconnaissance (ISR) community's name for this sequence. The same work is governed in U.S. joint doctrine by the Chairman of the Joint Chiefs of Staff. JP 2-01, Joint and National Intelligence Support to Military Operations (5 July 2017), sets the doctrine for how joint forces task collection and then process, exploit, and disseminate what they collect. The reason the five steps are named together is that each one is a separate point of failure. A gap in any single step breaks the chain, and the cycle is only as fast as its slowest link.
Key takeaways
TCPED runs in five sequential stages, but it functions as a loop: the product of one cycle becomes the tasking of the next as requirements shift. The first two stages, tasking and collection, acquire the data. The last three, processing, exploitation, and dissemination, are the PED half that converts it into a product and delivers it.
| Stage | What it does | What breaks here | Where AI helps |
|---|---|---|---|
| Tasking | Assigns a collection requirement to the right sensor or asset, and prioritizes it against everything else the asset could be doing | Requirements exceed assets, so high-value needs wait behind lower ones; re-tasking is too slow to catch a fleeting target | Prioritizes and de-conflicts requirements against asset availability, and proposes re-tasking as new intelligence arrives |
| Collection | Acquires raw data about the target: imagery, signals, intercepts, geospatial, and other feeds | The asset collects the wrong thing, or far more than anyone downstream can process | Flags coverage gaps and redundant collection before the data piles up unexploited |
| Processing | Converts raw feeds into a form an analyst can work with: decoding, formatting, georeferencing, transcribing, translating | Volume overwhelms the pipeline; raw data sits unprocessed and never reaches an analyst | Decodes, formats, georeferences, transcribes, and translates at scale, with the analyst confirming fidelity |
| Exploitation | The analytic step: reading processed material to extract meaning, identify entities and activities, and judge significance | Analyst-hours cannot keep pace with processed volume, so collected data is never exploited | Detects, labels, and correlates objects and activities across sources; the analyst accepts, corrects, or rejects each call |
| Dissemination | Delivers the finished product to the people who need it, at the classification and in the form they can use, in time to act | Intelligence arrives too late, at the wrong classification, or never reaches the decision-maker | Formats and routes products by need-to-know and releasability; the human owns the release decision |
The discipline of TCPED is keeping all five stages moving at the pace the mission sets, not just the one a given team happens to be good at. Collected data no one processes is wasted collection. Exploited intelligence no one receives in time is a missed decision.
TCPED and the intelligence cycle are related but not interchangeable. TCPED is the ISR-specific workflow for one path: getting a sensor tasked and turning what it collects into a delivered product. The intelligence cycle, and its current doctrinal successor the joint intelligence process, is the broader framework that governs all intelligence work, not just ISR collection.
The traditional intelligence cycle is usually taught as a loop of planning and direction, collection, processing, analysis and production, and dissemination. Doctrine notes the model is an idealization: JP 2-0 observes that "intelligence actions do not always follow sequentially through the cycle," because a request can draw on archived material without triggering new collection. The current JP 2-0, Joint Intelligence (22 October 2013) replaces the older cycle with a joint intelligence process of six interrelated categories: planning and direction; collection; processing and exploitation; analysis and production; dissemination and integration; and evaluation and feedback.
The honest distinction is this. The joint intelligence process includes a dedicated analysis and production stage and a formal evaluation-and-feedback loop that TCPED does not name separately. TCPED folds the analytic judgment into exploitation and treats the whole sequence as a collection-to-delivery workflow. They overlap because they describe the same underlying work at different scopes.
| Framing | What it spans | How it treats analysis |
|---|---|---|
| TCPED | Tasking, collection, processing, exploitation, dissemination (the ISR collection-to-delivery path) | Analytic judgment is inside exploitation; no separate analysis-and-production stage |
| Traditional intelligence cycle | Planning and direction, collection, processing, analysis and production, dissemination | Analysis and production is a named, distinct stage |
| Joint intelligence process (JP 2-0) | Planning and direction; collection; processing and exploitation; analysis and production; dissemination and integration; evaluation and feedback | Analysis and production is distinct, with a formal evaluation-and-feedback loop around the whole sequence |
Reading the table top to bottom, the wider the frame, the more of the lifecycle it names. The practical point is that TCPED is the view you use when the question is about ISR throughput, while the joint intelligence process is the view you use when the question is about the full production of finished all-source intelligence.
Processing, exploitation, and dissemination (PED) is the back half of TCPED: the three stages that convert collected data into an intelligence product and deliver it. Processing makes the raw feed legible, exploitation extracts what it means, and dissemination gets the result to the decision-maker in time. PED is named apart from collection because it is funded, manned, and constrained separately. A command can buy more collection and still be unable to use it, because the people and tools that process and exploit the data have not scaled with the sensors.
PED is where most of the delay and most of the backlog in TCPED actually live, which is why it has its own doctrine, its own dedicated cells, and its own modernization pressure. This page frames the full ISR workflow; the companion, processing, exploitation, and dissemination (PED), goes deeper on the three middle stages, the PED cell, and how PED sits inside the broader joint intelligence process. If your question is specifically about the conversion step rather than the full cycle, start there.
Collection outruns exploitation
Collection routinely outruns the capacity to process and exploit it, so the TCPED bottleneck is almost never the sensor. It is the analyst-hours and data pipeline in the middle of PED.
JP 2-01 notes that collection requirements routinely exceed available collection and PED capacity. AI takes on high-volume processing and exploitation work; the analyst keeps authority over each call, and every product stays traceable to its source.
The ISR PED bottleneck is the condition in which collection has outrun the capacity to process and exploit it, so the constraint on finished intelligence is not the sensor but the analyst-hours and data pipeline behind processing and exploitation. As sensor counts climb, the volume of collected data grows faster than the people and tools available to turn it into meaning, and prioritization becomes a standing part of the job rather than an exception.
Joint doctrine treats this as a normal operating condition, not a crisis. JP 2-01 is explicit that collection requirements routinely exceed available collection and PED capacity, so teams cannot process and exploit everything they gather and must decide what to work first. See JP 2-01. The constraint sits squarely in the middle of the TCPED cycle, between a sensor that has already collected the data and a decision-maker who still has not received a product.
The same shortage reappears one layer down when a command tries to automate its way out of the backlog. The U.S. Government Accountability Office found that acquiring and curating usable, labeled data is a central challenge in fielding AI for defense; its report notes that detecting an adversary's submarines "requires gathering many images of various submarines and labeling them so the AI can learn to identify one on its own." See GAO-22-104765 (2022). The exploitation bottleneck does not disappear when you add automation. It moves into the data pipeline that feeds the automation, which is why a credible TCPED modernization plan treats data readiness and auditability as first-order problems, not afterthoughts.
AI accelerates TCPED by moving the routine, high-volume conversion work off the analyst so human judgment goes where it matters, at machine speed and with a traceable record at every step. It helps most in the stages where volume is the enemy: prioritizing tasking against limited assets, flagging collection gaps, processing raw feeds into readable form, and detecting and correlating entities during exploitation. The analyst stays accountable for the call, accepting, correcting, or rejecting each machine result, and every step keeps a record so a product can be defended later against the question of how it was derived.
Two properties make this a data and reasoning problem rather than a model problem alone. First, the data is fragmented. A single conclusion can depend on an image, an intercept, a geospatial track, and a text report, each in a different format and system. No one feed resolves the target; the answer only exists in the correlation across them, and correlating fragmented multi-source data at machine speed is exactly the work that multi-INT fusion and all-source intelligence depend on. Second, in defense intelligence the audit trail is not optional. The failure mode to avoid is full automation that removes the human checkpoint, and the provenance with it. Decision support with a human in the loop is the design, not a limitation of it. The companion page AI-enabled ISR and PED automation covers how this automation works across the cycle in practice.
Torch.AI does not sell a sensor or a collection platform, and this page is not a claim to one. The front half of TCPED, tasking and collection, is owned by the sensors and the collection community. What Torch.AI builds is the government-owned reasoning infrastructure the back half depends on: the ability to turn fragmented, multi-source collection into coherent understanding at machine speed while keeping every product traceable to the collection it came from.
The fit is specific to the middle of the cycle, where the PED bottleneck lives. NEXUS makes multi-source ISR output meaningful through semantic representation and Knowledge Domains, so processed material from different sensors and formats can be reasoned over as one body of evidence. HALO makes the relationships among entities, events, and sources understandable through graph-based fusion and reasoning, the connective work that exploitation depends on. Both run on ORCUS, the government-owned data-availability layer, so the authoritative sources stay intact and every derivation remains inspectable. Because this runs as a system of reason on top of existing collection systems rather than replacing them, the customer keeps control of the layer where collected data becomes understanding, and a disseminated product stays defensible after the fact. You can see how this is packaged on the Torch.AI software page.
For evaluators, the fit is specific: if your TCPED problem is that collection arrives faster than your teams can process and exploit it, that is a data and reasoning problem, and it is the one this infrastructure is built for. Request a technical walkthrough and we will run it against a representative slice of your own multi-source collection, with provenance traced end to end.
ISR tradecraft and collection assets are doctrine and hardware. The modern gap is the data capability underneath processing, exploitation, and dissemination. If you are evaluating infrastructure to accelerate the back half of TCPED, require:
Evaluating a capability? Bring these six requirements to a scoping call and we will walk each one against your environment and a sample of your collection: request a technical walkthrough.
The five stages are tasking, collection, processing, exploitation, and dissemination. Tasking assigns a requirement to a sensor; collection acquires the data; processing makes it readable; exploitation extracts its meaning; and dissemination delivers the finished product to the decision-maker in time to act. The last three stages are known together as processing, exploitation, and dissemination (PED).
TCPED is the ISR-specific workflow for turning a collection requirement into a delivered product. The broader intelligence cycle, and its doctrinal successor the joint intelligence process in JP 2-0, adds a distinct analysis-and-production stage and a formal evaluation-and-feedback loop around the whole sequence. TCPED folds analytic judgment into exploitation and names only the collection-to-delivery path, so the two overlap but are not identical.
PED is the back half of TCPED: the three stages that convert collected data into an intelligence product and deliver it. Processing makes the raw feed legible, exploitation extracts what it means, and dissemination gets the result to the decision-maker. PED is named apart from collection because the people and tools that process and exploit data are funded and constrained separately from the sensors.
The ISR PED bottleneck is the condition in which collection has outrun the capacity to process and exploit it, so the constraint on finished intelligence is the analyst-hours and data pipeline behind processing and exploitation, not the sensor. JP 2-01 states that collection requirements routinely exceed available collection and PED capacity, which makes prioritization a standing part of the job.
AI accelerates TCPED by moving routine, high-volume conversion work off the analyst: prioritizing tasking, flagging collection gaps, processing raw feeds into readable form, and detecting and correlating entities during exploitation. The analyst accepts, corrects, or rejects each result and every step keeps a traceable record, so automation carries the volume while the human carries the authority and the audit trail.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe where your TCPED cycle stalls. We will scope the session around your collection, with provenance traced end to end. No sensor pitch. Your multi-source data. Real work.
