The Joint Terminal Attack Controller operates at the most consequential junction in modern combat aviation: the point where ground observation, aircraft delivery capability, and rules of engagement converge into an authorization to release ordnance within hundreds of meters of friendly forces. The procedures that govern this junction — the nine-line CAS brief, the clearance chain, the mark-type confirmation — were designed for voice radio and have worked, imperfectly, for decades. Digital tools do not replace these procedures; they change the medium through which the procedures execute, and in doing so they address the specific failure modes that voice radio cannot.
This article examines what those digital tools look like in practice: how automated 9-line generation works, how target coordinates reach aircrew without a voice readback cycle, how airspace deconfliction is enforced without manual cross-referencing, how ROVER video integrates with the ground picture, how fires coordination software deconflicts CAS with indirect fire support through AFATDS, and what happens to the digital workflow when the network fails. The architecture described here applies equally to JTACs controlling fixed-wing attack aircraft and to joint fires observers (JFOs) calling for indirect fire — the underlying data model and deconfliction logic are the same.
The JTAC workflow from target acquisition to ordnance delivery
A CAS sortie passes through a predictable sequence of phases regardless of platform or target type. Understanding where digital tools intervene — and where they do not — requires mapping the workflow precisely.
The sortie begins with target acquisition: the JTAC observes a target through direct optics, receives a digital handoff from a sensor platform, or identifies a target on the ROVER video feed. In a digital-native workflow this observation is immediately logged as a provisional COP marker — MGRS coordinate, target type from a structured taxonomy, time of acquisition, and confidence level. The COP marker is the origin record for everything that follows.
The JTAC then constructs the 9-line brief. In a voice workflow this is a mental exercise executed against a memorized format. In a digital workflow the 9-line form opens pre-populated with data from the COP marker: target location, calculated distance and heading from the designated initial point, and target elevation from the terrain database. The JTAC reviews and completes the remaining fields — mark type, target description, friendly forces — and submits the request through the approval chain.
The approval chain — JTAC to Air Forward Air Controller (AFAC) to authorizing authority in deliberate CAS, or JTAC directly to AFAC in time-critical — exists on shared map data in a digital workflow. The approving authority sees the same kill box geometry that the JTAC assembled, not a coordinate string they must mentally project onto a map. Approval is a deliberate action tied to a visible spatial display, not a voice acknowledgment that may or may not reflect a complete understanding of the target geometry.
On approval, the target coordinate is pushed to the aircraft's navigation system via datalink where capability exists, and the JTAC marks the target with the designated mark type — laser, IR pointer, or GPS coordinate. The aircraft attacks. The JTAC observes through ROVER video if available, and records battle damage assessment against the sortie record. If re-attack is required, the BDA entry generates a new 9-line pre-populated from the updated target location.
Digital tools intervene at five of these phases: acquisition logging, 9-line generation, approval visualization, coordinate handoff, and BDA recording. The attack execution phase — the physical act of marking and observing — remains entirely in the hands of the JTAC. That boundary is intentional: digital close air support augments human judgment at the information-handling phases; it does not automate the terminal control decision.
9-line CAS request software
The 9-line CAS request form is the most failure-sensitive document in close air support. A single field error — a transposed MGRS digit in line 6, an incorrect bearing in line 2, an understated friendly forces distance in line 8 — can place ordnance on the wrong target or on friendly troops. Digital 9-line software addresses this risk by replacing free-text radio transmission with a structured schema that enforces types, validates consistency, and provides visual confirmation at every consequential field.
Automated coordinate population. When the JTAC opens the 9-line form with an active COP target marker, line 6 (target location) auto-populates from the marker's coordinates in both MGRS and decimal lat-lon. The system converts between formats automatically and stores both representations with explicit datum tagging (WGS84). A visual confirmation prompt displays the coordinate as a point on the map and asks the JTAC to confirm: "Is this the correct target location?" The confirmation step is mandatory — the field cannot be accepted without it — and the confirmation is logged with the JTAC's operator identity and a timestamp.
Distance and heading calculation. Lines 2 and 3 (attack heading and distance from IP to target) are auto-calculated from the IP and target location fields when both are populated from the COP. The calculated values are displayed alongside the form fields as a spatial diagram — the IP, the attack axis arrow, and the target point are rendered on a mini-map inset in the form — so the JTAC can verify that the geometry matches their understanding of the attack geometry before submitting. Manual override is permitted but logged as a deviation from the calculated value.
Target elevation from terrain database. Line 4 (target elevation in feet MSL) auto-populates from the terrain database for the target coordinate. The source and age of the terrain data are displayed alongside the field — a DTED Level 1 dataset from 2019 requires more caution than a recent survey-derived DEM. The JTAC accepts or overrides the database value; an override requires entry of the JTAC's assessment basis (direct observation of terrain features, recent imagery, etc.).
Structured target description. Line 5 uses a hierarchical taxonomy rather than free text: primary category (vehicle, personnel, structure, equipment, infrastructure), secondary classification within that category, and a free-text remarks field for details that do not fit the taxonomy. Structured classification enables automated ROE checks at submission time — the system can flag whether the target type falls within pre-authorized categories or requires additional approval routing.
Friendly forces cross-validation. Line 8 (friendly forces location relative to the target) is the highest fratricide risk field in the 9-line. The JTAC enters a bearing and distance — "300 meters south" — and the system cross-validates that entry against actual COP friendly track positions. If the nearest friendly track in the COP is 150 meters south rather than 300 meters, the discrepancy generates a warning. The JTAC must acknowledge the discrepancy explicitly and confirm which value is correct. This cross-validation does not block submission — the JTAC has ground truth that the COP may not reflect — but it surfaces the discrepancy rather than silently accepting a potentially incorrect field.
Coordinate conversion error checking. Any coordinate entry — whether MGRS, lat-lon, or UTM — is parsed against the coordinate system's validity rules and cross-checked against the operational area bounding box. A grid reference that falls outside the theater of operations, or that fails checksum validation, generates a blocking error before the JTAC can submit. This catches the most common category of transcription error: a digit that is technically valid as a coordinate but places the target in the wrong 100km MGRS square.
Target coordinate handoff and laser/RFID marking integration
The target coordinate handoff from JTAC to aircrew is the step where a voice workflow introduces the last and most consequential transcription risk: the pilot manually entering a grid into their navigation system from a voice readback. Digital handoff eliminates this step entirely for platforms with compatible datalinks.
Steer-point push via datalink. On 9-line approval, the system pushes the target coordinate to the aircraft's mission computer as a steer-point via the appropriate datalink for the platform: Link 16 for coalition fast-movers with JTIDS avionics, SADL (Situational Awareness Datalink) for A-10 Warthogs and some rotary-wing platforms, or platform-specific waveforms for special operations aviation. The pushed steer-point is designated with the sortie ID so both the JTAC and the pilot can confirm they are referencing the same target record. A confirmation message from the aircraft — "steer-point received, grid confirmed" — closes the handoff loop in the digital record.
When direct datalink push is unavailable — older aircraft, cross-coalition platforms without interoperable waveforms — the system generates a formatted steer-point upload file compatible with the aircraft's mission planning system, or a structured voice brief formatted for minimal readback error. Either way, the target coordinate in the approved 9-line record is the authoritative source, and any deviation between that record and the loaded steer-point is flagged if the pilot's data link supports reverse confirmation.
SOFLAM and IZLID laser code integration. When the mark type in line 7 is laser, the laser code — the four-digit PRF code that the aircraft's laser spot tracker uses to discriminate the correct designator from any other lasers on the battlefield — must reach the aircraft without voice transmission error. Digital tools handle this by storing the laser code in the JTAC's equipment profile, auto-populating it into the 9-line line-7 field, and including it in the datalink push to the aircraft. If SOFLAM or IZLID integration is available via a digital interface (some variants support USB or serial configuration), the system can query the designator's current code setting and auto-confirm that the code in the 9-line matches the code programmed on the hardware.
Target box and steer-point display on ROVER. When the JTAC's ROVER terminal has cursor-on-target overlay capability — a software feature available on ROVER 6 and later generations — the approved target COP marker is georegistered to the ROVER video feed. The target location appears as a crosshair overlay on the video image, allowing the JTAC to verify visually that the aircraft sensor is pointed at the correct aimpoint before clearance. If the crosshair and the aircraft's apparent aimpoint diverge, the JTAC has a direct visual indicator of a targeting error before weapons release.
Airspace deconfliction for CAS
Airspace deconfliction for CAS is not a single check — it is a continuous process that spans from kill box definition through to post-strike airspace release. Airspace deconfliction software automates the most time-consuming elements of this process: cross-referencing the kill box against active airspace control measures, calculating altitude blocks, and sequencing conflicting users through temporal separation.
Lateral and vertical kill box definition. The kill box is defined by a center point (the target location from line 6), lateral radius (determined by weapon type, collateral damage estimation, and terrain), and altitude block (minimum and maximum altitude for the attack run). These three parameters together define the three-dimensional volume that must be deconflicted against all other airspace users before the JTAC can proceed to approval.
ACM coordination. Airspace control measures — restricted operating zones, minimum risk routes, no-fly areas, joint engagement zones, and free-fire areas — are maintained in the airspace management layer and updated from the Air Tasking Order and Airspace Control Order feeds. The deconfliction module overlays the proposed kill box against all active ACMs at the moment of submission. Any overlap generates a specific conflict report: which ACM is violated, who the controlling authority is, what the valid time window is, and whether a coordination request can be routed digitally to that authority. For temporary restricted areas and ATC holds, the coordination request is automated — the system sends a request to the controlling authority's digital interface and waits for approval or an alternative window assignment.
Altitude block management. The kill box altitude block must be coordinated not only against static ACMs but against all dynamic airspace users: other CAS sorties in the same area, artillery trajectories (deconflicted through the fires layer), ISR platforms holding at medium altitude, and any air defense radar coverage that requires notification before aircraft enter a defined volume. The deconfliction module maintains a real-time picture of altitude block allocations and assigns the requesting CAS sortie to an altitude window that does not conflict with existing reservations. If the JTAC's requested altitude block cannot be accommodated without conflict, the module offers the next available window and displays the wait time.
Temporal deconfliction. When two CAS sorties require overlapping airspace volumes but not simultaneously, temporal deconfliction assigns execution windows rather than lateral or vertical separation. The first sortie is allocated a window from T+0 to T+8 minutes; the second sortie holds and takes T+10 to T+18 minutes. The JTAC sees their assigned window on the approval interface and plans the attack execution accordingly. A sortie that overruns its window generates an alert to both the JTAC and the airspace manager, because the overrun creates a conflict with the next allocated sortie.
ROVER/TRAC integration for CAS
ROVER (Remotely Operated Video Enhanced Receiver) gives the JTAC what no other tool provides: the same visual picture the aircraft sensor operator is using to identify and engage the target. In a voice-only workflow the JTAC and the pilot are looking at a shared coordinate but not a shared picture — the JTAC is looking at the ground through binoculars, the pilot through a targeting pod, and the two images may not agree on which feature is the intended target. ROVER collapses this gap.
Cursor-on-target overlay. Digital integration between ROVER and the CAS C2 software adds the cursor-on-target overlay to the video feed: the approved target COP marker is georegistered to the ROVER video frame using the aircraft's sensor metadata (slant range, gimbal angle, aircraft position and altitude). The target location appears as a crosshair symbol on the video. If the crosshair is on a different building than the one the pilot's sensor is aimed at, the JTAC can detect the discrepancy before clearance and initiate a talk-on to correct the aircraft's aim.
Laser spot tracker display. ROVER variants that include laser spot tracker (LST) capability detect the JTAC's laser spot on the video image and display its location as a second symbol on the cursor-on-target overlay. The JTAC can see, in real time, whether the laser spot is on the target feature designated by the crosshair or offset from it — a common problem when terrain occludes line-of-sight between the JTAC and the target. If the laser is off-target, the JTAC adjusts designation without requiring a voice exchange with the pilot.
Software-defined ROVER (TRAC integration). TRAC (Tactical Remote Viewing System) and subsequent software-defined video receiver implementations allow the aircraft sensor feed to be streamed to any networked device — a ruggedized tablet, a laptop, a smartphone in an emergency — rather than requiring a dedicated ROVER hardware terminal. The CAS C2 software receives the video stream via standard RTSP or STANAG 4609 MISB-compliant transport and renders it in the same interface as the 9-line form and COP display. A single screen shows the JTAC the 9-line status, the COP kill box, and the aircraft video feed simultaneously — eliminating the head-switching between a ROVER terminal, a map, and a radio that characterized earlier-generation CAS coordination.
Fires synchronization with AFATDS and the FDC
Close air support rarely operates in isolation from indirect fires. Artillery and mortar assets may be suppressing adjacent enemy positions, providing SEAD fires before the CAS aircraft ingresses, or covering the JTAC's egress route after the strike. Deconflicting these simultaneous fires — ensuring that an artillery projectile does not enter the CAS altitude block while an aircraft is on final — requires a digital connection between the JTAC's CAS coordination tool and the fires command-and-control system.
Digital call-for-fire from the COP. When a JTAC or JFO calls for indirect fire support from the same target record used for CAS, the digital CFF message is generated from the existing COP marker — same MGRS coordinate, same target description taxonomy, same sortie ID for cross-reference. The CFF routes to the fire direction center (FDC) via AFATDS, appending the fires observer's credentials and the method of observer (ground observer, UAV, aircraft). If the same target receives both a CAS request and a CFF request, the two are linked in the fires coordination layer by the shared sortie ID, creating a unified fires synchronization record.
Deconfliction between CAS and indirect fires. AFATDS maintains a queue of active and planned fire missions with their trajectories, time-on-target windows, and altitude envelopes. The CAS deconfliction module queries this queue before approving a CAS altitude block. If any active fire mission's trajectory enters the CAS altitude block over the target area during the planned attack window, the deconfliction module generates a hold request to the FDC: "Hold fire on mission [ID] — CAS altitude block conflict from T+3 to T+9." The FDC adjusts timing and releases the CAS altitude block. The hold and release are logged with timestamps in the fires synchronization record.
SEAD coordination. Suppression of enemy air defenses before a CAS attack run requires sequencing SEAD fires to arrive before the CAS aircraft enters the defended envelope and to clear before the aircraft exits — not before it enters. Digital tools maintain a SEAD timing record linked to the CAS sortie: the threat air defense system location and type, the SEAD fire mission assigned to suppress it, and the window during which suppression is confirmed active. The CAS approval workflow checks that SEAD fire missions are confirmed in the AFATDS queue before clearing the CAS aircraft for ingress. A SEAD fire mission that is delayed or denied generates a hold in the CAS approval chain, with the JTAC shown specifically which SEAD mission is blocking the clearance.
The fires synchronization architecture also handles the reverse case: indirect fire missions that must deconflict with active CAS altitude blocks already reserved in the airspace management layer. AFATDS integration with the airspace management feed allows the FDC to see active CAS altitude blocks before accepting a new fire mission, and to route new missions through trajectories that avoid occupied altitude blocks rather than relying on the JTAC to detect and call a cease-fire.
Lessons from digital CAS adoption
Digital CAS tools have been deployed in operational environments long enough to reveal consistent failure patterns that inform both architecture and training. These lessons are not hypothetical — they reflect recurring observations from post-mission reviews of CAS operations where digital tools were part of the kill chain.
Connectivity constraints in contested environments. Electromagnetic environments that degrade communications also degrade the data links that digital CAS tools depend on. ROVER video is the most bandwidth-intensive component and the first to fail; cursor-on-target overlay becomes unavailable without the video feed. TAK COP synchronization requires a narrower channel and degrades more gracefully — the COP picture freezes rather than disappearing, displaying the last known positions of friendly tracks. 9-line form submission and approval messaging can operate over very narrow MANET channels and store-and-forward mesh networks. AFATDS CFF messaging typically uses a resilient tactical radio data link. Tools must be designed and JTACs must be trained to understand exactly which capabilities degrade at which bandwidth thresholds, and to shift to appropriate degraded-mode procedures without waiting for a complete link failure.
Automation complacency. Auto-populated fields — target location from COP, distance from geometry, elevation from terrain database — reduce cognitive load during high-tempo targeting but create a new failure mode: the JTAC accepts a pre-populated value without verifying it. In post-mission reviews, instances of incorrect target location have been traced to COP marker placement errors that the JTAC did not catch because the auto-populated coordinate "looked right" without a deliberate check. Interface design must make auto-populated fields visually distinct from manually entered fields, require an explicit confirmation action for each high-stakes field, and display the field's data source so the JTAC knows what they are confirming.
Mode confusion in approval workflows. Deliberate and time-critical CAS require fundamentally different approval workflows, and JTACs under time pressure consistently attempt to route time-critical requests through deliberate CAS queues when the interface does not make the distinction obvious. The mode-switch from deliberate to time-critical CAS must be a persistent, visible interface state — not a menu option or a form checkbox — because a JTAC who is simultaneously managing radio communications, observing the target, and coordinating with the aircraft does not have cognitive bandwidth to notice a subtle UI state difference. If the mode is wrong, the sortie takes three minutes longer than the engagement window allows.
Degraded-mode procedures as primary skills. JTACs who train exclusively on digital tools and treat voice 9-line as a backup skill they will "remember when needed" consistently perform poorly when digital links fail in training exercises — and the performance gap is worse under operational stress than in training. Digital CAS tools should be introduced as an accelerator for a voice-proficient JTAC, not as a replacement for the voice skill. Training programs that use digital tools from the first day of CAS qualification produce JTACs who can use the tools fluently but cannot perform effectively when the tools are unavailable. The discipline of treating degraded-mode operation as a primary skill — not a contingency — is the single most important human factors lesson from digital CAS adoption.