Target folder management: building and maintaining the target system

A target is not a coordinate. It is a structured body of knowledge – accumulated intelligence, physical description, functional analysis, collateral risk assessment, and command authority – organized into a target folder that persists from the moment of nomination through post-strike battle damage assessment. Target folder management software is the system that holds this knowledge, enforces the workflows that govern how it is built and approved, and keeps the joint target list (JTL) synchronized with the operational picture. This article examines how that software is architected, what data it must manage, and how it integrates with the broader common operating picture and C2 environment.

The target folder: data model and required fields

The target folder is the authoritative record for a single target throughout its lifecycle in the targeting system. Its data model must accommodate several categories of information that span different classification levels, source types, and update cycles.

Location and geometry. The nominated target location (NTL) is a WGS84 coordinate assigned during nomination. As development proceeds, the NTL is refined to a mean point of impact (MPI) – the coordinate against which weapons will be aimed. The target folder stores both values, with associated accuracy figures: a circular error probable (CEP) or the equivalent datum accuracy statement from the source intelligence. If the target occupies an area (a depot, airfield, or command node with multiple functionally significant components), the folder stores a polygon footprint in addition to the MPI.

Target identification and description. Every target receives a target serial number (TSN) assigned by the targeting software at nomination. Additional identification fields include the target category (from a standardized target category list aligned with doctrinal target system analysis frameworks), the target name, and cross-references to existing intelligence database entries for the same object. The physical description section holds structured fields covering the target's size, construction type, above-ground and below-ground extent, and distinguishing features visible in imagery.

Functional analysis. The targeting officer documents which components of the target are functionally critical – those whose destruction or neutralization would achieve the desired effect – and which are redundant or secondary. This analysis drives the weaponeering step: the selector must know which aimpoint produces the desired effect, not merely which coordinate places the weapon inside the target boundary.

Intelligence source records. Every data element in the folder carries a source reference: the intelligence report, imagery product, or human reporting that supports it. Source references include classification markings, originator, and date. The software must support multiple classification levels within a single folder, with field-level access control that prevents users without the requisite clearance from seeing classified source details while still being able to work with the sanitized target record.

Collateral damage estimation data. Collateral damage estimation (CDE) is a mandatory step before any target can be approved for engagement. The folder stores the CDE input data – imagery of surrounding structures, distance measurements to protected sites, population density estimates – and the CDE results for each weapon option considered. Because CDE results are invalidated by coordinate changes or changes to the surrounding environment, the software must version CDE records and flag them for recalculation when their input data changes.

The joint targeting cycle and software workflow

The joint targeting cycle provides the procedural framework within which target folder management software operates. The cycle has six phases, and the software's workflow engine mirrors each phase with configurable status transitions and routing rules.

Phase 1: Commander's guidance. Before targeting begins, the commander issues guidance that defines the target system (what category of targets supports the operation's objectives), the desired effects, constraints, and any targets that are off-limits due to operational, legal, or political considerations. This guidance is encoded in the targeting software as campaign-level configuration: a list of approved target categories, a list of restricted and no-strike objects (populated from the restricted target list and no-strike list databases), and effect thresholds that the CDE methodology must not exceed without elevated command approval.

Phase 2: Target development. The targeting cell nominates targets and populates their folders. The software enforces a minimum-content checklist before a folder can be promoted from 'nominated' to 'development complete' – all required fields must be populated and all source references attached. Incomplete fields are flagged in the UI, and the checklist drives the targeting officer's workflow rather than relying on manual tracking in spreadsheets or shared documents.

Phase 3: Weaponeering and capabilities analysis. The weaponeering officer selects weapon-aimpoint combinations that achieve the desired effect against the critical components identified in the functional analysis. The targeting software stores weaponeering results as structured records linked to specific aimpoints in the target geometry, with the weapon type, fuze setting, delivery parameters, and predicted effects. CDE is run for each weapon option considered, and the results determine which options are available at the approved command authority level.

Phase 4: Force application. Approved targets are added to the joint target list and assigned to attack platforms – aircraft, artillery, or electronic warfare – through the air tasking order (ATO) or equivalent tasking mechanism. The targeting software records the assignment and updates the target status to reflect that engagement is planned. Integration with the artillery fire control C2 layer is a key interface at this phase: the targeting software must pass aimpoint coordinates, fuze data, and effect requirements to the fire control system, and receive execution confirmation back.

Phase 5: Execution planning and execution. Once assigned, targeting officers monitor execution status via the targeting software's integration with the operational C2 picture. When a platform reports execution – weapon release or fires execution – the targeting software records the execution event and triggers the BDA workflow.

Phase 6: Assessment. Battle damage assessment data – imagery, signals, or ground reporting – is entered as a structured assessment record in the target folder. The assessment workflow compares the observed effects against the desired effects from Phase 1, classifies the result (target destroyed, target damaged and re-attack required, target undamaged), and generates a re-attack recommendation if the desired effect was not achieved. The completed BDA record closes the targeting cycle for that target; targets requiring re-attack are returned to the JTL with updated folders.

Target list management: the JTL as a live database

The joint target list is not a static document – it is a live database view that changes continuously as targets are nominated, developed, approved, engaged, and assessed. Target folder management software maintains the JTL as a filtered, sorted query over the underlying target database, with configurable views for different users and command levels.

The JTL view exposes targets grouped by category, effect, or geographic area of operations. Targeting officers can filter by target status, priority, assigned platform, or time window. Commanders see a summary view with target priority, JTL position, and execution status. Legal advisors see the CDE and proportionality review queue. Each role sees the same authoritative data from the same database, differentiated only by access control and display configuration.

Target prioritization on the JTL is driven by a scoring model that incorporates the target's contribution to the commander's objectives, time sensitivity (does the target have a limited window during which it is available or vulnerable?), and the cost of engagement in terms of platform availability and risk. The software records the prioritization rationale, which is important for post-operations review and for demonstrating that targeting decisions were made in accordance with the command's guidance and applicable law.

No-strike and restricted target list integration

The no-strike list (NSL) and restricted target list (RTL) must be integrated into the targeting software at the data layer, not as a UI-level check. Every target folder is automatically cross-referenced against the NSL and RTL when coordinates are entered or updated. If a target's MPI falls within the proximity threshold of a protected site – a hospital, school, cultural property, or religious site – the software flags the potential conflict and requires explicit acknowledgment from the approving officer before the target can be advanced. The proximity threshold is configurable per category of protected site and per the applicable rules of engagement.

NSL and RTL data is maintained as a separate, controlled database that is synchronized to the targeting software from the higher command. The update mechanism must be reliable and auditable: every change to the NSL or RTL is recorded with a timestamp, source authority, and the specific objects added or removed. Targets whose NSL/RTL proximity status changes due to an NSL update – not a target movement – must be re-flagged for review even if their own data has not changed.

Software architecture: the targeting database and its interfaces

The core of target folder management software is a structured relational database with a document store for attachments – imagery thumbnails, full-resolution imagery products, CDE worksheets, and assessment reports. The relational layer holds the target record with all structured fields; the document store holds binary and large-text attachments keyed to the target serial number.

The targeting database must support concurrent editing by multiple targeting officers, with conflict detection and resolution for the shared fields (JTL priority, target status, aimpoint coordinates). Version history for all structured fields is a baseline requirement: targeting authorities must be able to reconstruct the state of any target folder at the time of any approval or execution event for post-operations legal review.

Integration interfaces connect the targeting software to the rest of the C2 environment. The primary interface is the COP layer, which consumes approved target records from the JTL as geospatial overlays – target reference points, named areas of interest, or engagement zones published as map features. This interface is bidirectional: execution events and BDA inputs flow back from the COP and ISR layers into the targeting database. A secondary interface connects the targeting software to the fires coordination system for direct transfer of aimpoint data, weapon parameters, and execution confirmation. See the related treatment of JTAC and CAS coordination software for the close air support coordination workflow that operates in parallel with the deliberate targeting cycle.

Classification handling and multi-domain access control

Target folders aggregate data from multiple intelligence sources operating at different classification levels. A single folder may contain unclassified imagery from commercial satellites, secret-level signals intelligence, and top-secret human reporting – all describing the same target. The software must implement field-level classification labels and enforce them at the API layer, not only in the presentation layer.

The practical implication is that a targeting officer with a secret clearance and a targeting officer with a top-secret clearance may see different versions of the same target folder. Both see the target's coordinates, category, and JTL status. Only the higher-cleared officer sees the HUMINT-derived functional analysis. The software must render a coherent, consistent view to each user based on their access level – not simply blank out fields, which creates confusion about whether data exists.

Coalition operations add a further dimension: partner-nation personnel may have equivalent clearance levels but different national caveats that restrict access to intelligence from specific sources. The access control model must support caveat-based filtering in addition to classification-level filtering, and must be configurable for each coalition's sharing rules without requiring software customization.