What are the four steps of JIPB and how does software support each one?

Joint intelligence preparation of the battlefield (JIPB) follows four sequential steps. Step 1, define the battlespace environment, establishes the area of operation (AO) and area of interest (AOI) boundaries and identifies which characteristics of the battlespace are relevant to the mission. Software supports this step through geographic information system (GIS) tools that allow analysts to draw AO/AOI polygons, import authoritative boundary data from higher headquarters, and query terrain feature databases for relevant characteristics such as road network density, bridge load classification, and urban extent. Step 2, describe the battlespace effects, analyzes how terrain, weather, and civil considerations affect both friendly and threat operations. Software automates terrain analysis overlays — mobility corridors from digital elevation models (DEMs), observation and fields-of-fire calculations, cover and concealment analysis — and integrates weather forecast data to model effects on specific weapon systems and aviation operations. Step 3, evaluate the threat, builds and maintains models of adversary forces, doctrine, and capabilities. Software manages order of battle (ORBAT) databases, equipment capability tables, and doctrinal template libraries, and generates threat models from these components. Step 4, determine threat courses of action (COA), develops adversary COA models based on the threat evaluation and the battlespace effects analysis. Software supports COA development through enemy COA modeling tools, decision point identification, and automated wargaming frameworks that test each COA against friendly options.

What geospatial data formats does JIPB software typically ingest?

JIPB software must handle the full range of geospatial data formats used across coalition and national intelligence systems. Vector formats include Esri Shapefile, GeoJSON, KML/KMZ, GeoPackage (GPKG), and Military Overlay Data Converter (MOVD) formats used in NATO systems. Raster formats include GeoTIFF for imagery and DEM data, National Imagery Transmission Format (NITF) for national intelligence products, DTED (Digital Terrain Elevation Data) at levels 1 and 2 for terrain analysis, and CIB (Controlled Image Base) for orthorectified imagery. Service-based data access uses OGC standards: WMS and WMTS for raster tile services, WFS for vector feature services, and WCS for coverage data including elevation. Modern JIPB platforms also ingest commercial satellite imagery delivered via STAC (SpatioTemporal Asset Catalog) APIs, enabling integration with commercial EO constellations for near-real-time imagery updates within the AO. The platform's projection handling must support both geographic coordinates (WGS84) and projected coordinate systems (UTM, MGRS grid zones) without requiring the analyst to manually reproject data before loading.

How does JIPB software calculate mobility corridors from terrain data?

Mobility corridor analysis is one of the most computationally intensive functions in JIPB software. The process begins with a digital elevation model (DEM) from which the software derives slope in degrees for every cell in the analysis area. Slope thresholds for cross-country mobility are vehicle-class-dependent: wheeled vehicles typically cannot exceed 30% slope, tracked vehicles can manage up to 60% slope on suitable surfaces. The software applies a trafficability model that combines slope with soil type (from geotechnical databases or soil survey data), vegetation density (derived from land cover classification), and surface drainage classification (from hydrological analysis of the DEM and stream network data). Cells that exceed mobility thresholds for the specified vehicle class are masked out. The remaining passable terrain is analyzed using least-cost path algorithms — typically Dijkstra's algorithm or A* on the cost surface — to identify the routes through the terrain that minimize travel time or energy expenditure for the modeled force. The output is a set of vectorized mobility corridors ranked by throughput capacity, width of the passable corridor, and choke point locations where the corridor narrows to a single route.

What is a doctrinal template and how is it generated by JIPB software?

A doctrinal template represents how a threat force deploys and operates according to its standard doctrine, independent of the specific terrain. It is derived from the threat's published or assessed tactics, techniques, and procedures (TTPs), force structure, and historical patterns. JIPB software generates doctrinal templates from a threat doctrine library: the analyst selects the threat unit type (for example, a motorized rifle battalion on the offense), the echelon, and the operational mode (attack, defense, delay, march). The software retrieves the associated template parameters — formation geometry, inter-unit spacing, security element positioning, support element locations, and expected communications architecture — and renders the template as a scalable overlay. The template exists in the software's template library as a reusable object parameterized by the reference point (the unit's center of mass or main effort), scale (adjustable for terrain), and orientation (the direction of attack or main axis). The doctrinal template becomes the starting point for the situational template: the analyst overlays the doctrinal template on the actual terrain, adjusting it to account for terrain constraints, observed deviations from doctrine, and current intelligence on the specific unit's habits and preferences.

How does weather effects analysis integrate with JIPB software?

Weather effects in JIPB software are structured around the concept of go/no-go thresholds for specific military capabilities. The software ingests numerical weather prediction (NWP) model output — typically in GRIB2 format from national meteorological services or military weather support units — and translates forecast parameters (wind speed, precipitation rate, temperature, cloud base height, visibility, humidity) into effects on specific weapon systems and operational capabilities. Aviation effects analysis computes whether forecast conditions meet or exceed the minimums for rotary-wing close air support, fixed-wing low-altitude attack, and unmanned aerial system operations. Direct fire effects modeling calculates how precipitation, humidity, and temperature affect the performance of specific projectile types and laser designation. Indirect fire tables integrate wind speed and direction at multiple altitudes to model dispersion for artillery and rocket systems. Electronic warfare effects analysis models how atmospheric ducting, precipitation attenuation, and temperature inversion affect radar propagation and electronic warfare system range. The software produces a weather effects matrix — a time-phased table showing which friendly and threat capabilities are degraded at each forecast period — and overlays forecast weather data on the geographic map to show where and when conditions change across the AO.

What data is stored in a JIPB threat ORBAT database?

An order of battle (ORBAT) database in JIPB software is a structured representation of the adversary force. Each unit record contains: a unit identifier (designation, echelon, type, country, and parent unit); location data (last known position with grid reference, position confidence, and timestamp); strength data (personnel count by category, equipment counts by type, assessed combat effectiveness); equipment records linked to a capability database (specifying the performance envelope of each weapon system, sensor, and vehicle type in the unit's table of organization); and command relationships (unit hierarchy, reporting relationships to parent and subordinate units). The ORBAT database maintains a change history for each unit record, allowing the analyst to view the historical sequence of position and strength reports and identify patterns of movement or reinforcement. Location data for each unit is stored with a positional uncertainty ellipse derived from the source accuracy and age of the reporting intelligence, allowing the threat COA model to propagate position uncertainty into the resulting COA probability distributions. The database is accessible as a layer in the map interface, showing unit symbology per MIL-STD-2525 or APP-6 standards, and as a structured data export for analytical tools.

How does JIPB COA analysis differ from friendly COA analysis in C2 systems?

Friendly COA analysis in a C2 system is synchronization planning: the planner specifies what friendly forces will do, and the system helps sequence and deconflict those actions. Enemy COA analysis in JIPB is fundamentally probabilistic: the analyst does not specify what the enemy will do but instead models what the enemy is likely to do given the force composition, terrain, weather, and doctrinal tendencies, and assigns probability weights to multiple alternative COAs. JIPB software supports this by building enemy COA models from the threat evaluation outputs rather than from manual planning inputs. The software retrieves the adversary's force composition from the ORBAT database, the terrain constraints from the battlespace effects overlays, and the relevant doctrinal templates from the threat library, and proposes candidate COA structures that are geometrically consistent with the terrain analysis and doctrinally appropriate for the assessed unit type. The analyst refines the proposed COAs, assigns probability weights based on the collection indicators that have been observed, and identifies decision points — the locations and times at which the adversary must commit to one COA versus another. These decision points drive the collection plan: intelligence collection assets are tasked to observe the decision point locations so that early COA identification is possible before the adversary force reaches the point of commitment.

What is an event template and how is it generated by JIPB software?

An event template is a product of JIPB Step 4 (determine threat COA) that identifies the named areas of interest (NAIs) and the observable events that indicate which COA the adversary is executing. It is a companion to the situation template: where the situation template shows where the adversary will be at each phase of each COA, the event template shows where collection assets should look to observe the indicators that distinguish between COAs. JIPB software generates event templates from the COA models by analyzing the divergence points between COAs: the geographic locations and time windows where the adversary force's posture or movement would be observably different depending on which COA it is executing. The software identifies the highest-information observation point for each divergence — the NAI where observing a specific event (for example, a bridge crossing, a resupply convoy movement, or a communications configuration change) most clearly confirms or denies a specific COA. Each NAI record in the event template contains the geographic polygon of the observation area, the list of events that confirm or deny each COA when observed there, the recommended collection asset type, the collection window, and the report format for observations. The event template feeds directly into the collection plan and the intelligence synchronization matrix.

How does JIPB software support the decision support matrix (DSM)?

The decision support matrix (DSM) is a planning product that links enemy decision points to friendly actions — specifically, to the branch plans and contingency actions the commander will execute if the enemy takes a particular COA. JIPB software generates the decision point component of the DSM from the COA analysis: for each adversary decision point identified in the COA models, the software records the decision point location, the time window by which the adversary must commit, the observable indicators that will confirm the decision, and the threshold for confirmed versus denied. The C2 system's planning module then links each decision point to the corresponding friendly branch plan trigger — the intelligence threshold that authorizes the commander to execute the contingency action. The DSM in JIPB software therefore becomes an operational handshake between the intelligence estimate and the operational plan: the intelligence staff maintains and updates the decision point estimates as collection reporting comes in, and the operations staff uses the confirmed/denied status of each decision point to execute the right branch of the operational plan. Modern JIPB platforms automate the DSM update by ingesting collection reports against NAIs and automatically updating the confirmed/denied status of associated decision points when reporting crosses the specified threshold.

How does JIPB software integrate with real-time intelligence feeds during execution?

The JIPB process does not end when the operation begins. During execution, the threat situation evolves as the adversary reacts to friendly actions, and the JIPB products must be updated continuously. JIPB software integrates with real-time intelligence feeds through a combination of data interfaces: cursor on target (CoT) feeds from ISR platforms deliver position reports that update ORBAT unit locations in near-real-time; SIGINT reporting feeds update the electronic order of battle; and imagery exploitation products update the situation template as new imagery is collected and analyzed. The software flags deviations from the predicted COA: when an adversary unit is observed at a location inconsistent with its predicted position in the active COA model, the system generates an analyst alert and recalculates COA probabilities based on the new observation. This feedback loop — plan, collect, assess, revise — is the continuous JIPB cycle during execution. Integration with real-time intelligence fusion platforms, where all-source intelligence is correlated and fused before being written to the common operating picture, allows JIPB software to receive pre-correlated reports rather than raw single-source data, reducing the analyst's burden during the high-tempo execution phase when time for manual correlation is most limited.

What output formats does JIPB software produce for dissemination?

JIPB software produces intelligence products in both graphic and text formats for dissemination across the command. Graphic products include the situation template (SITEMP) as a geospatial overlay exportable to GEOTIFF, KML/KMZ, or the tactical data format used by the C2 system's common operating picture; the event template as a layer containing NAI polygons with associated collection requirements; and the modified combined obstacle overlay (MCOO) as a vector layer combining mobility corridors, obstacles, and key terrain designations. Text products include the intelligence estimate in structured XML or JSON format for machine-to-machine dissemination, the weather effects matrix as a formatted table, and the ORBAT in MTF (message text format) for exchange with adjacent units and higher headquarters. All products carry metadata that includes the assessment date-time group, the classification and handling caveats, the producing unit, and the next scheduled update. Versioning is maintained in the JIPB software's product registry: each time a SITEMP or event template is updated, the previous version is archived and the new version is published with an increment to the version number and a summary of what changed, so recipients can quickly identify what is new without reviewing the entire product.

What is the modified combined obstacle overlay and how is it produced?

The modified combined obstacle overlay (MCOO) is the primary terrain analysis product of JIPB Step 2 (describe battlespace effects). It synthesizes mobility analysis, obstacle data, key terrain identification, and observation/fields-of-fire analysis into a single overlay that shows how the terrain channels both friendly and threat movement. JIPB software produces the MCOO through a sequence of automated terrain analysis steps: first, the mobility analysis masks non-traversable terrain for the specified vehicle class; second, existing obstacles (rivers, urban areas, dense forests, man-made barriers from engineer obstacle records) are overlaid as mobility restrictors; third, the remaining passable terrain is vectorized into mobility corridors classified as unrestricted, restricted, or severely restricted; fourth, key terrain features — ground that must be controlled to dominate the surrounding terrain — are identified using a combination of terrain dominance analysis (viewshed calculations) and doctrinal key terrain criteria; and fifth, observation and fields-of-fire polygons are calculated from the key terrain positions to show what can be observed and engaged from each. The MCOO is rendered as a layered geospatial overlay following standard military cartographic symbology, with each terrain category shown in the appropriate pattern (green cross-hatch for restricted terrain, red obstacles for impassable features, blue arrows for mobility corridors).

How does JIPB software handle civil considerations analysis?

Civil considerations analysis — the ASCOPE (Areas, Structures, Capabilities, Organizations, People, Events) framework — is the component of JIPB Step 2 that evaluates how the civilian environment affects military operations. JIPB software supports civil considerations through a structured database of civil information overlaid on the operational map. Areas are represented as polygons: populated areas by size and density from census and geospatial databases, agricultural zones, industrial areas, and restricted access zones derived from host nation legal frameworks or rules of engagement designations. Structures of military significance — bridges, ports, airfields, communications nodes, power generation facilities, water treatment plants — are recorded as point or polygon features linked to technical specifications: bridge load classification and width, airfield runway dimensions and surface type, power plant output capacity. Organizations are tracked as structured records of civilian organizations (NGOs, local government bodies, tribal structures, criminal networks) with locations, leadership, and assessed disposition toward the operation. People categories are mapped as demographic overlays showing population density, language and ethnic distribution, and displacement patterns. Events are tracked as a time-stamped log of significant civil events — markets, religious observances, protests, atrocities — that affect the operational environment. The ASCOPE database in JIPB software is shared with the civil-military operations cell and feeds into the operational planning products.

JIPB software: joint intelligence preparation of the battlefield tools and workflows

The joint intelligence preparation of the battlefield (JIPB) process generates the intelligence foundation that every other planning function depends on. Without a completed JIPB, planners do not know which terrain channels threat movement, which weather window degrades adversary aviation, or which of the three assessed enemy COAs is most likely. The problem is time: a thorough manual JIPB at brigade level requires hundreds of analyst-hours per cycle. JIPB software compresses that timeline by automating the most labor-intensive analytical steps — terrain analysis from digital elevation data, threat model construction from ORBAT databases, COA geometry derivation from doctrinal templates — while preserving the analyst's authority over the judgment calls that determine which outputs are correct. This article examines the software architecture behind each JIPB step, the data models that underpin the analysis, and the intelligence products the platform generates for dissemination to the command. For context on the broader military intelligence analysis software ecosystem in which JIPB tools operate, see our dedicated architecture overview.

The four JIPB steps and where software fits

JIPB is a four-step process defined in doctrine: define the battlespace environment, describe the battlespace effects, evaluate the threat, and determine threat courses of action. Each step produces outputs that feed the next, and each presents distinct automation opportunities.

Step 1 — Define the battlespace environment establishes the geographic and functional boundaries of the analysis: the area of operation (AO), the area of interest (AOI), and the characteristics of the battlespace that affect the mission. The analyst identifies which terrain, weather, and civil factors are operationally significant. Software automation in this step centers on boundary management tools and geospatial database queries that retrieve relevant terrain characteristics without manual cartographic research. A JIPB platform can automatically extract road network density, bridge inventory, urban extent, and hydrographic barrier data within the AO boundary the moment the boundary is drawn, replacing what was previously a multi-hour manual data collection task.

Step 2 — Describe the battlespace effects is the most computationally amenable step. Terrain analysis — computing slope, deriving mobility corridors, calculating observation polygons from key terrain — is geometric computation that software performs in minutes from digital elevation and land cover data. Weather effects analysis maps forecast meteorological parameters to military capability thresholds. Both functions are well-suited to automation because the underlying models are deterministic: given the same DEM and the same vehicle mobility parameters, the software produces the same mobility corridor analysis every time.

Step 3 — Evaluate the threat requires maintaining a structured model of the adversary force: its composition, equipment, doctrine, and current disposition. Software handles the data management challenge — maintaining an order of battle database that integrates new reporting, tracks unit movements, and links equipment records to capability specifications — while the analyst makes the interpretive judgments about what the reporting means.

Step 4 — Determine threat COAs is the most analytically demanding step. The analyst develops two to four adversary COA models that are doctrinally plausible, geographically feasible given the terrain analysis, and consistent with the assessed force composition. Software assists by generating candidate COA geometries from doctrinal templates applied to the terrain, automating the timeline derivation from distance and assessed movement rates, and identifying the decision points where COAs diverge observably. The analyst refines and assigns probability weights; the software manages the model structure and generates the downstream products.

Battlespace definition and geographic data management

The geospatial data layer is the foundation on which every JIPB analysis function runs. JIPB software manages this layer through a combination of boundary management tools, terrain feature databases, and geospatial data integration interfaces.

AO/AOI boundary management is more than drawing polygons on a map. The software registers the AO and AOI boundaries as active filters that clip analysis outputs, focus database queries, and define the geographic scope for terrain analysis runs. When a higher headquarters changes the AO boundary — a common occurrence during operational planning — the software must propagate that change to all dependent analysis layers. JIPB platforms implement this through a boundary dependency graph: each terrain analysis layer that was computed within the previous AO boundary is flagged as potentially stale when the boundary changes and queued for re-computation.

Terrain feature layer management organizes the raw geospatial data into operationally meaningful feature categories. The platform maintains separate layers for the road network (with attributes including road surface type, width, and bridge load classifications for each segment), the hydrographic network (streams classified by width and bank steepness), the settlement layer (populated places classified by size and building density), and the vegetation layer (land cover classification with height estimates). Each layer is queryable: the analyst can ask the system to identify all river crossings within the AO with a bridge load rating below 60 tons, or all settlements with a population density above a specified threshold within 5 km of a named axis of advance.

Geospatial data integration handles the heterogeneity of data sources used in operational environments. JIPB software ingests data from national mapping agency datasets, commercial satellite-derived products, open-source databases, and intelligence community geospatial repositories. The integration layer handles projection conversion, datum transformation, attribute schema normalization, and conflict resolution when two sources show different values for the same feature. Data quality metadata — source, collection date, accuracy specification, and classification — is preserved at the feature level so the analyst knows the provenance of every terrain feature used in the analysis.

Terrain analysis automation

Terrain analysis automation is where JIPB software delivers its most measurable time savings. Tasks that required trained cartographers working for hours with manual overlay techniques are replaced by processing runs that complete in minutes. The core analysis functions are mobility corridor analysis, trafficability modeling, cover and concealment analysis, and observation/fields-of-fire calculation.

Mobility corridor analysis from DEM data begins with slope computation. The software derives a slope raster from the digital elevation model, typically expressed in degrees or percent. Slope values are then classified against mobility thresholds for the specified vehicle class:

Vehicle class	Slope limit	Cross-country speed (unrestricted)
Wheeled light vehicle	<30%	Up to 40 km/h on firm, flat terrain
Wheeled heavy (8×8 APC)	<30%	Up to 25 km/h, sensitive to soft soil
Tracked IFV / light tank	<60%	Up to 30 km/h cross-country
Main battle tank	<60%, soil-dependent	Up to 20 km/h, high ground pressure limits soft terrain use

The slope passability mask is combined with a trafficability model that integrates soil type, drainage class, and seasonal conditions. Wet clay soils that are passable in summer become impassable after rain; sandy soils that appear challenging on slope analysis are often more passable than clay soils on gentler slopes. The software applies a soil mobility scoring function derived from geotechnical databases and hydrology analysis to produce a combined passability raster that is more operationally accurate than slope alone.

Cover and concealment analysis classifies terrain cells by their ability to protect forces from observation and direct fire (cover) versus observation alone (concealment). The software uses the land cover classification to identify vegetation canopy density, building density in urban areas, and terrain masking from ridgelines. Concealment polygons are calculated as viewshed complements — areas not visible from a set of representative observation positions — and classified by vegetation density, which determines whether the concealment also provides ballistic cover.

Observation and fields-of-fire calculation runs a viewshed analysis from each key terrain position identified by the analyst. The viewshed algorithm computes, for each observer position and height, all terrain cells within a specified range that have a direct line of sight to the observer. The output is a set of observation polygons that show the maximum observable area from each key terrain feature. For fields-of-fire analysis, the same computation is parameterized with weapon system range envelopes and minimum engagement range constraints, producing a direct-fire coverage polygon that represents the ground a weapon system emplaced at the key terrain can engage.

# Pseudocode: mobility corridor derivation from DEM

slope_raster = compute_slope(dem, unit="percent")

soil_score   = query_soil_trafficability(aoi, vehicle_class)

passable     = (slope_raster < threshold[vehicle_class]) AND (soil_score >= MIN_PASS)

corridors    = vectorize(least_cost_paths(cost_surface(passable), origin, destination))

corridors    = classify_width(corridors, passable)  # unrestricted / restricted / severely restricted

Weather effects analysis

Weather effects analysis in JIPB software translates meteorological forecast data into military capability assessments. The analyst needs to know not just what the weather will be, but what the weather means for specific operational capabilities at specific times and locations in the AO.

Forecast data integration connects the JIPB platform to the operational meteorological service. The standard data exchange format for numerical weather prediction output is GRIB2, which encodes atmospheric parameters on a regular grid at multiple pressure levels and forecast lead times. The JIPB weather module ingests GRIB2 files and interpolates the forecast grid to the AO extent, producing local forecast time series at any point the analyst queries. Multiple forecast models — the Global Forecast System, the European Centre for Medium-Range Weather Forecasts model, or the military tactical weather system — can be ingested simultaneously, with the platform displaying model agreement and divergence to indicate forecast uncertainty.

Weapon system weather impact tables encode the go/no-go thresholds for each capability type. The platform maintains a library of weapon system and platform profiles, each specifying the meteorological parameters and thresholds that determine operational availability. Aviation profiles include minimum ceiling height, minimum flight visibility, maximum cross-wind component, and maximum precipitation rate for each aircraft type. Direct fire weapon profiles specify the maximum wind speed at which fire control solutions are reliable, humidity effects on laser rangefinder performance, and temperature effects on propellant charge ballistics. Indirect fire tables specify dispersion adjustments for wind speed and direction at multiple altitudes in the trajectory envelope.

The weather effects matrix generated by the software is a time-phased table — rows are forecast periods, columns are capability types — with each cell coded green (capability available), amber (degraded, within parameters), or red (below minimums, not available). The matrix is derived automatically from the forecast data applied against the capability threshold library, with the analyst able to override individual cells where judgment or local knowledge differs from the automated assessment.

Aviation weather decision aids extend the basic weather effects matrix with route-specific analysis. For planned aviation routes within the AO, the software calculates forecast ceiling and visibility values at each waypoint along the route and at each time-window option for the mission. Where forecast conditions fall below mission minimums at a specific waypoint, the software flags the segment and suggests the earliest window in the forecast period when conditions are predicted to improve. Icing risk, turbulence potential, and density altitude effects on aircraft performance at high-elevation airstrips are computed as additional aviation-specific overlays.

Threat model databases

The threat evaluation step requires a structured data model of the adversary force that is rich enough to support COA development but maintainable by an intelligence cell under operational tempo. JIPB software manages this through three interconnected database components: the ORBAT database, the equipment capability database, and the TTPs and threat doctrine library.

ORBAT management maintains the hierarchical record of adversary units, from strategic-level formation down to platoon or individual platform where intelligence reporting permits. Each unit record contains the unit identifier (designation, echelon type, parent formation, nationality), last known location with positional uncertainty, strength assessment (personnel and equipment by category), and assessed combat effectiveness. The ORBAT database maintains a timestamped history of each record: every change — a new position report, an updated strength assessment, a change in higher headquarters — is recorded with the intelligence source and collection date-time group rather than overwriting the previous value. This history enables the analyst to track unit movement patterns and identify anomalies that may indicate preparation for an offensive action or a deception operation.

Equipment capability databases link each unit's equipment holdings to performance specifications used in COA modeling. A motorized rifle battalion in the ORBAT has associated records for its vehicle types (with cross-country speed, road speed, fuel consumption, and ground pressure), its weapons systems (range, rate of fire, ammunition types, and weather limitations), and its organic communications systems (frequency range, range, and network architecture). These specifications feed directly into COA timeline generation — the software computes how long a specific unit configuration would take to traverse a given route by applying the vehicle speed parameters to the mobility corridor analysis output — and into real-time intelligence fusion models that estimate unit locations at future times based on observed starting positions and assessed movement rates.

TTPs library and threat doctrinal template generation encode the adversary's standard operating procedures as reusable template objects. A doctrinal template for a motorized rifle battalion conducting an attack specifies the typical formation geometry — the spacing between companies, the positioning of the artillery battalion in relation to the maneuver elements, the depth of the advance guard — as a set of relative positions parameterized by a reference point and a direction of attack. When the analyst selects this template and places the reference point on the terrain, the software renders the full template in correct geographic orientation and scale. The analyst then adjusts the template to account for terrain constraints: a mobility corridor that forces the battalion to compress from a two-company frontage to a one-company frontage through a defile will cause the software to recalculate inter-unit spacing to maintain the same depth in a narrower formation. The resulting terrain-adjusted template is the situation template for that COA.

COA analysis and wargaming support

Enemy COA development is the culminating analytical product of JIPB. The analyst develops two to four adversary COA models, each representing a doctrinally plausible and geographically feasible option that the adversary might execute. JIPB software supports COA development through COA modeling tools, automated timeline generation, and decision point identification.

Enemy COA modeling builds on the doctrinal templates and terrain analysis to construct complete COA geometries. For each candidate COA, the analyst specifies the adversary's objective, the axis of advance or defense sector, and the echelon of effort. The software retrieves the appropriate doctrinal template, overlays it on the MCOO to identify terrain constraints, and generates the COA geometry as a set of phase lines, axes of advance, and assembly areas positioned on the actual terrain. The COA geometry is stored as a structured geospatial object — not a static image — so it can be queried, updated, and used to generate downstream products automatically.

Automated timeline generation computes the time-phased sequence of events for each COA. Given the COA geometry (the route from assembly area through line of departure to objective), the assessed vehicle types in the ORBAT, and the terrain mobility analysis, the software calculates the expected arrival time at each phase line for each unit in the COA model. Timeline generation accounts for the mobility constraints in the MCOO — a corridor classified as severely restricted reduces the modeled movement rate below the platform's road-march speed — and for doctrinal preparation times (time required for an artillery preparation, for engineer obstacle breaching, for assembly area-to-line-of-departure movement). The output is a time-phase diagram that shows where each adversary element is expected to be at each hour of the operation under each COA.

Decision point identification is one of the highest-value automation functions in COA analysis. A decision point is the location and time at which the adversary commander must commit to a specific COA — after which the observable behavior of the force will diverge in ways detectable by collection assets. The software identifies decision points by comparing the COA geometries: the geographic point where COA 1 and COA 2 would have the adversary force on different route segments is the decision point, and the time at which the adversary must be at that point to execute either COA within doctrinal timing constraints is the decision point time. Decision points drive the collection plan: intelligence assets are tasked to observe the decision point location during the decision window so that COA confirmation or denial is possible before the adversary is committed. The platform also supports the parallel tool — a structured COA comparison that evaluates each COA against the same set of criteria (feasibility, suitability, acceptability, distinguishability, completeness) — and supports the wargaming step by maintaining a record of each action-reaction-counteraction sequence tested against each COA.

Intelligence product generation

The outputs of the JIPB process are a set of structured intelligence products that the command uses for planning and during execution. JIPB software automates the generation and formatting of these products from the analytical work completed in the preceding steps, and manages versioning and dissemination.

Automated situation template (SITEMP) output renders the COA model geometries as a military cartographic overlay following standard symbology. The SITEMP shows the adversary force disposition at a specified time under the most likely or most dangerous COA, using MIL-STD-2525D or APP-6E unit symbols positioned according to the COA model. The software generates multiple SITEMP frames — one for each significant time phase in the COA timeline — that together constitute an animated picture of the adversary's expected progression. SITEMP overlays are exportable as geospatial layers (GeoTIFF, KML, or native C2 format) so they can be loaded directly into the common operating picture without manual redrawing.

Automated event template output generates the named area of interest (NAI) polygons and indicator tables from the decision point analysis. Each NAI is a geographic polygon positioned at the decision point location, annotated with the list of observable events that confirm or deny each COA when observed there, the collection asset type best suited to observe the NAI, the priority relative to other NAIs, and the time window during which observation must occur. The event template as a whole constitutes the indicator matrix that drives the collection plan. Like the SITEMP, the event template is exported as a geospatial overlay and as a structured table for the intelligence synchronization matrix.

Decision support matrix output links the event template's NAIs and indicators to the friendly branch plans they trigger. The software generates the intelligence side of the DSM — the decision point locations, times, and indicator thresholds — and provides a structured data interface that the C2 planning module uses to associate each decision point with the corresponding friendly branch plan trigger. The JIPB platform's responsibility ends at the decision point definition; the C2 system's responsibility is to monitor collection reporting against NAIs and alert the commander when a trigger threshold is crossed. This is enabled by integration of JIPB software with the broader intelligence workflow, including NLP for military intelligence reports that allows incoming SPOT and SALUTE reports to be automatically matched against active NAIs and evaluated for indicator relevance without manual analyst triage.

Product versioning and dissemination is a critical operational function that is frequently underspecified in JIPB software designs. In operational practice, JIPB products are updated multiple times per day as new intelligence arrives and COA assessments change. Recipients — adjacent units, higher headquarters, subordinate commanders — must be able to distinguish the current version of a product from a superseded version without reading the entire product from scratch. JIPB software manages this through a product registry that tracks every published product by version number, publication date-time group, producing unit, and a change summary that describes what was updated in the current version relative to the previous one. Dissemination is logged: the platform records which units received which version of each product, enabling the intelligence officer to identify units that are operating from a superseded product and notify them of the update. Product expiration timestamps alert the intelligence cell when a product is approaching its validity limit and a refresh cycle is required.

The combination of automated terrain analysis, structured threat modeling, software-assisted COA development, and formatted product generation reduces the time to produce a complete JIPB from days to hours at brigade level, and from hours to tens of minutes for a focused update to a single JIPB step. The remaining time is spent on what software cannot replace: the analyst's judgment about which terrain the threat commander will actually prefer, which doctrinal template deviations the specific unit in question is known to employ, and which of the three assessed COAs is most consistent with the commander's intent the intelligence suggests the adversary is pursuing. JIPB software does not automate those judgments — it ensures the analyst has the structured data, formatted products, and dissemination infrastructure to make them well and communicate them quickly.