.svg){kind=icon}
Order of battle (OB) is the intelligence picture of an adversary force: its composition, disposition, and strength, along with the command relationships, equipment, and behavior that show how the force is organized and where it is, maintained continuously so analysts can assess the threat and anticipate how it will act.
Also written OOB or ORBAT, and called order-of-battle analysis, adversary force structure, or military threat modeling.
What makes OB hard is that it is relational and perishable at the same time. A force is a hierarchy of units with command relationships, equipment holdings, and locations, and every one of those can change. Doctrine treats it as a set of factors to maintain, not a document to file, which means the real capability is the one that keeps the picture current as new reporting arrives.
That makes OB a graph problem the same way target system analysis is: units are nodes, command relationships are edges, and the picture is only as good as the resolution and fusion beneath it. You cannot track a force you have not first resolved into distinct units (entity resolution) and fused from all sources (multi-INT fusion).
Key takeaways
The clearest statement of the problem is the government's own modernization effort. The Defense Intelligence Agency is replacing the Military Intelligence Integrated Database (MIDB), in use since the 1980s, with the Machine-assisted Analytic Rapid-repository System (MARS), and oversight has documented both the need and the risks (U.S. Government Accountability Office, Defense Intelligence: Comprehensive Plan Needed to Improve Stakeholder Engagement in the Development of a New Military Intelligence System, GAO-21-57, 2020). Foundational military intelligence, the all-source picture of other countries' militaries, is exactly order of battle at scale, and the legacy system could no longer keep pace with the volume and velocity of data.
DIA's public descriptions of the program make the shape of the demand explicit: MARS includes an order-of-battle module built to automatically track foreign military forces, depicting unit hierarchy together with geographic location and assigned equipment, on top of a data environment intended to make existing data ready for AI and machine learning. The program's stated goal is decision advantage, higher-quality adversary information reaching warfighters faster. That is a government requirement, expressed in a program of record, for order of battle that is living rather than static.
The analytic reason the old model breaks is that OB is relational. A unit's significance comes from where it sits in a command hierarchy, what it is co-located with, and what it is equipped to do, none of which a flat record captures well. When the picture is maintained by hand across disconnected systems, it falls behind the moment the adversary reorganizes. The demand is for a picture that updates as reporting arrives and shows the structure, not just the roster.
For the mission the payoff is a current, defensible understanding of the adversary force: who is where, under whose command, with what, assessed with confidence and traceable to the reporting behind it, rather than a table whose last update no one trusts.
Doctrine defines order of battle not as one attribute but as a set of factors maintained together. Joint intelligence preparation of the operational environment lists the adversary-situation factors that order-of-battle analysis assesses (U.S. Joint Chiefs of Staff, Joint Publication 2-01.3, Joint Intelligence Preparation of the Operational Environment, 2014):
The first three, composition, disposition, and strength, are the load-bearing core, but the point of doctrine is that they are tracked as a connected set. A change in disposition without the command relationship that explains it is a location without meaning. Order-of-battle analysis is the discipline of maintaining all of these factors as one coherent, current picture.
Order of battle maps onto a knowledge graph more naturally than onto a table: units are nodes, command and subordination are edges, and equipment, locations, and personalities attach to the nodes they belong to. Modeled this way, a change propagates correctly, reassigning a battalion moves its subordinates with it, and the picture reflects structure rather than a flat list of records. This is the same shape the government's own modernization adopts when it depicts unit hierarchy together with geographic location and equipment.
The contrast with the legacy model is the whole argument:
| Dimension | Static OB database | Living OB graph |
|---|---|---|
| Representation | Flat records in tables | Units as nodes, command relationships as edges |
| Handling change | Manual edits; easily inconsistent | Changes propagate through the hierarchy |
| Multi-source input | One system at a time | Resolved and fused across all sources |
| Currency | Decays between manual updates | Updates as reporting arrives |
| Analyst question | "What is the record for this unit" | "What is subordinate to this headquarters, and where" |
| Provenance | Often lost | Every node and edge traces to source |
The takeaway is not that structure is a nicety; it is that an adversary force is a structure, and representing it as one is what lets the picture stay current and answerable. An analyst can ask what sits under a given headquarters, or what moved into an area, and get an answer grounded in the graph with every element traced to its reporting, which is where GraphRAG and knowledge-graph fusion apply directly.
These terms cluster around adversary analysis and are easy to blur. The table separates them.
| Term | What it is | Relationship to order of battle |
|---|---|---|
| Table of organization and equipment (TO&E) | The doctrinal, intended composition of a unit type | The template; OB is the assessed reality, which often differs from the template |
| JIPOE / IPB | The process of analyzing the operational environment and adversary | The process within which order-of-battle analysis is performed |
| Target system analysis | All-source examination of a system's components and critical nodes | A related graph discipline; see target system analysis. OB characterizes the force; TSA examines a system for vulnerabilities |
| Threat model | A structured assessment of what an adversary can and might do | OB is the force-structure foundation a threat assessment is built on |
An order-of-battle picture is only as trustworthy as the entities in it. If reporting about the same unit under different designations is not resolved, the OB double-counts and inflates strength; if sources are not fused, the command relationship visible only across two reporting streams is never captured. The doctrinal factors presume the sources have been brought together first. That is the work of entity resolution and multi-INT fusion: resolution establishes the distinct units, fusion establishes the command relationships and locations, and order-of-battle analysis reads and maintains the resulting structure. Skip those steps and the picture inherits every duplicate and missed link as a wrong conclusion about the adversary force.
A maintained OB informs planning and assessment, so it has to be decision support, not an oracle. The machine's job is to assemble all-source reporting into a current, structured picture and surface changes, with confidence and provenance, at a speed no manual process can match. The analyst's job is to adjudicate: confirm an assessed command relationship, weigh a deception hypothesis, and own the judgment. Every element carries its sourcing and a confidence level, so a planner relying on the OB can see how firmly each piece is held and challenge it, consistent with the auditable discipline the rest of this hub requires. Automation earns its place by keeping the picture current and traceable; it does not replace the analyst who is accountable for it.
The sections above explain why currency, structure, and provenance matter; the checklist is what to require in an evaluation.
Evaluating a capability? The seven requirements above are the backbone of an order-of-battle evaluation you can score vendors against. Bring them 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. ORCUS ingests and normalizes all-source reporting, NEXUS reads the unstructured human, signals, and open-source text for the units, equipment, and relationships inside it, and HALO resolves those records and fuses them into a knowledge graph where units are nodes and command relationships are edges. That graph is a living order of battle: as new reporting arrives it updates the picture, propagates changes through the hierarchy, and keeps every node and edge traced to the reporting behind it, with a confidence level attached. You can see how this is packaged as a capability on the Torch.AI software page.
Because the picture is grounded in the graph with provenance preserved, it is built for the analyst rather than around them: they can interrogate the force, see why a unit is assessed where it is, and confirm or challenge it. This is the systems of record versus systems of reason distinction at the center of Torch.AI's approach: the reasoning layer maintains the adversary picture on top of the authoritative reporting, which stays intact, so the analyst owns an assessment they can defend.
Torch.AI's approach is built for the conditions this page describes: all-source, multi-INT reporting; a graph model of the force; continuous currency as reporting arrives; and classification-aware, provenance-preserving, analyst-in-the-loop decision support, deployable government-owned.
For evaluators scoping a capability, see how Torch.AI delivers resolution, fusion, and knowledge-graph analysis for a living order of battle on the software page, or request a technical walkthrough and we will run it against a representative all-source scenario, with provenance traced end to end.
What is order of battle in simple terms? It is the maintained intelligence picture of an adversary force: its composition, disposition, and strength, plus command relationships, equipment, and behavior. The value is keeping it current as the force changes, not compiling it once.
What are the order-of-battle factors? Doctrine lists factors including composition, disposition, strength, tactics, training, logistics, combat effectiveness, electronic technical data, and personalities, tracked together as one connected picture. Composition, disposition, and strength are the core. See the factors.
What is the difference between order of battle and a table of organization (TO&E)? A TO&E is the doctrinal, intended composition of a unit type; order of battle is the assessed reality of a specific adversary force, which often differs from the template because of losses, reorganization, and improvisation.
Why is order of battle treated as a graph? Because a force is a structure: units connected by command relationships, with equipment and locations attached. A graph lets changes propagate correctly (moving a headquarters moves its subordinates) and lets analysts ask structural questions, which a flat table cannot answer well.
Why is order of battle being modernized with AI? Because legacy databases could not keep pace with the volume and velocity of reporting. The government is replacing a decades-old system with an AI-enabled one whose order-of-battle module automatically tracks foreign forces, to deliver current adversary information faster (GAO-21-57).
Does automating order of battle remove the analyst? No. Automation keeps the picture current and traceable at machine speed; the analyst adjudicates assessments, weighs deception, and owns the judgment. Every element carries provenance and a confidence level so it can be challenged, consistent with auditable AI principles.