Voice radio has been the backbone of close air support coordination since World War II. A Joint Terminal Attack Controller (JTAC) reads a nine-line brief over HF or VHF to a fast-mover overhead, the pilot reads it back, and if all nine fields survive the noise floor and the phonetic alphabet without a transcription error, the attack proceeds. The procedural simplicity is deceptive: the error rate on voice 9-line transmissions in live conditions is substantially higher than in training, the readback creates a time penalty measured in minutes, and there is no visual confirmation that the coordinates the pilot received describe the same ground feature the JTAC is looking at.
Digital CAS coordination software addresses all three problems simultaneously. A structured form replaces free-text radio transmission, target location is linked to a live COP marker rather than spoken as a coordinate string, and the approval chain — JTAC to AFAC to authorizing authority — leaves an immutable audit trail from initial request to post-strike BDA. This article examines how to build that software: the data model, the COP integration architecture, the approval workflow patterns, and the deconfliction logic that makes digital CAS safer than its voice predecessor.
Where relevant, the article references how TAKpilot handles these problems in a TAK-native CAS workflow.
The JTAC workflow problem: why voice 9-line fails under pressure
The standard nine-line CAS request format was designed to convey exactly the information a pilot needs to find, identify, and engage a target: initial point and offset, attack heading, distance, target elevation, target description, target location, mark type, friendly forces position, and egress direction. Under controlled conditions the format works well. Under operational conditions it accumulates errors at every stage of the transmission chain.
The target location field — the most consequential field in the brief — is a coordinate string, typically in MGRS. Spoken over a degraded radio link at high tempo, a six-digit grid reference can be misheared in ways that move the target by hundreds of meters. The standard readback procedure catches gross errors but not subtle transpositions, because the pilot is reading back what they wrote down, not what the JTAC said. A four-digit MGRS error at 500 meters can put the attack on a wrong building. A six-digit error can put it on a different compound entirely.
Beyond accuracy, voice 9-line has no visual confirmation step. The JTAC and the pilot share a coordinate, not a picture. If the JTAC is looking at a building on the north side of a compound and the pilot resolves the coordinate to a building on the south side — a plausible outcome given coordinate precision — neither party has any mechanism to detect the discrepancy before weapons release. Digital CAS software closes this gap by displaying the same map overlay on both ends of the approval chain.
There is also no audit trail. A voice transmission exists in the memories of the participants and, if the radio is equipped for it, a voice recording. There is no structured record of which fields were transmitted, what corrections were made during readback, or what the approving authority actually reviewed before clearance. This gap matters enormously for post-incident LOAC review and for the institutional learning that prevents recurrence.
Digital 9-line message structure: from free text to typed schema
The first engineering decision in a digital CAS coordination system is the data model for the 9-line record itself. Each of the nine fields maps to a structured type — not a free-text string — with validation rules enforced at entry time.
Line 1 — IP/Offset. The initial point is stored as either a COP feature UID (if the IP is a named point already on the map) or a coordinate plus a label. The offset is a bearing in degrees magnetic and a distance in meters. The combination is rendered as a line on the map connecting IP to target, so the approving authority can visually confirm the geometry.
Line 2 — Heading. Integer bearing in degrees magnetic. The attack heading determines which direction the aircraft will be traveling when it crosses the target, which is relevant to collateral damage estimation and to the blast pattern for area munitions. The system renders the attack axis as an arrow on the kill box overlay.
Line 3 — Distance. Integer distance in meters from IP to target. Auto-calculated from the IP and target location fields when both are populated from the COP.
Line 4 — Target elevation. Integer elevation in feet MSL, auto-populated from the terrain database for the target coordinate when available. Manual override required if the JTAC assesses that the terrain model is stale or incorrect.
Line 5 — Target description. Structured type rather than free text: a primary category (vehicle, personnel, structure, equipment) with a secondary classification (wheeled vehicle, tank, command post, etc.) plus a free-text remarks field. Structured classification enables automated ROE checks against permitted target categories.
Line 6 — Target location. The highest-stakes field. Stored as MGRS (datum-tagged) and decimal lat-lon, auto-converted between formats. When the JTAC enters a grid, the system resolves it to a point on the map and prompts the JTAC to confirm visually: "Is this the correct location?" The point is displayed at the center of a proposed kill box so the confirmation context is spatial, not just numeric.
Line 7 — Mark type. Enumeration: laser (with laser code), IR pointer, smoke (with color), GPS (with coordinate), grid (coordinate only), none. If laser, the laser code field activates and auto-populates from the JTAC's registered equipment profile if available.
Line 8 — Friendly forces. The reported position of the nearest friendly troops relative to the target. Stored as a direction (cardinal or degrees) and distance, but cross-validated against actual COP positions: the system checks whether the reported bearing and distance are consistent with the nearest friendly track in the COP and flags significant discrepancies. This cross-validation catches the single most common fratricide risk factor — a JTAC who reports friendly forces at a location that does not match the actual COP picture.
Line 9 — Egress. The aircraft's planned exit direction after the attack run. Stored as a cardinal direction or a planned route UID if one has been filed with the airspace management layer.
COP integration: linking the 9-line to the live map
The digital 9-line form is not useful in isolation. Its value comes from integration with the common operational picture — specifically, from the ability to display the 9-line geometry on the same map that all actors in the approval chain are looking at simultaneously.
When a JTAC submits a 9-line request, the coordination software creates a set of COP objects that represent the request spatially. The target location becomes a provisional TAK marker with a distinctive symbology (a circle with crosshair, colored amber to indicate pending approval). The kill box — defined by the target location, a lateral radius appropriate to the weapon type, and an altitude block — becomes a geofence overlay. The attack heading becomes an arrow originating at the IP and passing through the target. The IP/offset line segment connects the IP to the target point.
All of these overlays are pushed as CoT events to the TAK server and appear on every connected ATAK or WinTAK client subscribed to the CAS coordination channel. The AFAC and the approving authority see the exact same geometry as the JTAC, without any coordinate interpretation step.
Aircraft track integration adds another layer of situational awareness. If the coordinating aircraft is transmitting its position — via TAK, ADS-B, or a data link feed — its track is displayed within the kill box overlay during the ingress phase. This allows the AFAC to visually confirm that the aircraft is on the correct attack axis and to detect any last-minute deviations before weapons release.
COP integration also provides real-time conflict detection. As the kill box overlay appears on the map, the system queries all friendly force markers within the lateral radius and altitude block. Any friendly track inside the kill box generates an immediate warning in the JTAC's interface and in the approving authority's approval prompt. The warning includes the track's designation, its current distance from the target, the time of last position update, and a visual indicator on the map showing exactly which track is inside the box.
Approval workflow: JTAC request to AFAC review to SMEAC clearance
The approval chain in a CAS operation exists to ensure that the right authority has reviewed the target, verified the geometry, and accepted accountability for the strike. Digital CAS coordination software must implement this chain rigorously — not as a bureaucratic form-routing exercise, but as a genuine check that the approving authority has seen the kill box on the map and actively chosen to clear the aircraft hot.
The workflow differs for deliberate and time-critical CAS. Deliberate CAS — planned attacks against pre-identified targets with adequate planning time — traverses the full SMEAC chain. The JTAC submits the completed 9-line, which routes to the Air Forward Air Controller (AFAC) for tactical review. The AFAC confirms the target geometry on the COP, checks for friendly force conflicts, verifies ROE compliance, and endorses the request. The endorsed request then routes to the Airspace Control Authority or the designated SMEAC approver for final authorization. Each step has a configurable timeout — if the approver does not act within the defined window, the request escalates or expires, depending on the mission-phase policy.
Time-critical CAS collapses the chain. The JTAC submits a streamlined brief — target location, mark type, friendly forces position, any restrictions — and the AFAC provides immediate clearance based on their own visual assessment of the COP. The SMEAC approval step is bypassed under a standing authority delegated at mission planning. The digital system enforces this distinction by routing time-critical requests on a separate queue with a shorter timeout and a simplified approval interface optimized for rapid action under stress.
Both workflows record every state transition in an append-only log: request submitted, AFAC review started, AFAC endorsed, SMEAC clearance granted, aircraft cleared hot. Each entry includes the acting operator's authenticated identity, their role in the approval chain, and a UTC timestamp precise to the second. This log is the primary evidence record for any post-strike review.
Deconfliction: airspace, fratricide prevention, and ROE compliance
Deconfliction in digital CAS software operates at three levels: airspace, fratricide, and rules of engagement. Each requires a different technical approach and a different response pattern when a conflict is detected.
Airspace deconfliction. Before a 9-line request can be approved, the kill box altitude block must be checked against active airspace reservations — restricted operating zones, minimum risk routes, ATC holds, and any blocks filed by other CAS sorties in the same area. In practice this requires integration with the airspace management layer, whether that is a dedicated Air Tasking Order feed, a TBMCS connection, or a manually maintained airspace control order overlay in the COP. Conflicts are displayed as overlapping geofence layers on the approval map. The approving authority must explicitly acknowledge an airspace conflict and accept coordination authority before clearance can proceed.
Fratricide prevention. The friendly forces validation described in the 9-line data model section is the first layer. The second layer is an automated check of all friendly tracks in the COP against the kill box geometry at the moment of approval. This check runs again at clearance-hot, not just at submission, because friendly forces may have moved between submission and approval. A track that was outside the kill box at submission but has moved inside by clearance generates a last-second blocking warning. The approving authority must re-review the map and re-confirm clearance — the initial approval does not carry forward past a changed COP state.
ROE compliance. The target description field's structured classification enables automated ROE checks. The system maintains a configurable ROE profile — updated at mission planning — that defines which target categories are pre-authorized, which require additional approval, and which are prohibited under current engagement authority. If the target description falls in a category requiring additional approval, the workflow routing adds an ROE review step. If it falls in a prohibited category, the request is blocked with an explicit error message citing the applicable ROE restriction. ROE override — acknowledging a restriction and proceeding anyway — is logged as a named action by the approving authority, not a silent system behavior.
TAKpilot integration: natural language CAS request to structured 9-line
One of the most operationally useful capabilities in TAKpilot is the ability to generate a structured 9-line draft from a natural language request. A JTAC can type or speak "engage the vehicle at grid 37T EL 441528, laser 1688, friendlies 300m south" and TAKpilot will extract the target location, mark type, laser code, and friendly forces information to pre-populate the 9-line form.
The natural language intake works as an accelerator for the structured form, not a replacement for it. The JTAC reviews every auto-populated field before submission — the system is explicit about which fields were auto-populated versus manually entered, so the JTAC knows exactly where to focus their verification. Fields that the NL parser could not confidently extract are left blank with a visual indicator, requiring manual entry.
Once the JTAC confirms the pre-populated form, TAKpilot submits the 9-line to the approval workflow and simultaneously pushes the target location marker and kill box overlay to CloudTAK via the TAK Server REST API. The AFAC receives an approval notification on their connected ATAK client, which opens the kill box overlay centered on the target. The approval interface shows the rendered kill box, the attack axis arrow, all friendly tracks in the area, and the pre-computed deconfliction check results. Clearance is a single deliberate action — not a casual tap — with a visual confirmation step that requires the approving authority to see the kill box on the map before the button activates.
This integration collapses the time from initial JTAC request to AFAC-reviewed, map-confirmed clearance to under 90 seconds in field tests, compared to 3–6 minutes for a voice 9-line transmission cycle with readback and clarification.
Bomb impact assessment: recording the post-strike picture
The CAS sortie record is not complete at clearance hot. Post-strike battle damage assessment (BDA) closes the loop from weapons release to effect achieved, and digital CAS coordination software must provide a structured BDA entry workflow linked to the originating 9-line record.
The BDA entry form activates automatically when the sortie status transitions to "attack complete." The JTAC enters: time of impact (UTC, populated from the GPS clock when available), weapon type and quantity delivered, observed effect (direct hit, near miss, miss with bearing and distance), crater or effect location in MGRS (entered from the JTAC's direct observation or from drone imagery if available), PT/PT assessment (whether the point target or personnel target was killed/suppressed/destroyed/missed), and initial collateral damage assessment.
If the first attack did not achieve the desired effect, the BDA entry triggers a new 9-line request pre-populated with the updated target location (the crater or remaining threat position) and a re-attack flag that accelerates the approval routing. This loop — strike, BDA, re-attack decision — can complete in under three minutes in a digital-native CAS workflow.
All BDA data is linked to the originating 9-line via the sortie ID and archived as part of the immutable sortie record. If drone or aircraft sensor imagery is available, a reference to the imagery asset is attached to the BDA record as a STANAG 4559 collection reference or a TAK data package link.
After-action: sortie log, 9-line archive, and timeline reconstruction
The operational value of digital CAS coordination extends well beyond the immediate mission. Every sortie record — complete with 9-line, approval chain, BDA, and all intermediate state transitions — is an asset for debrief, doctrine refinement, and institutional learning.
The sortie log provides a chronological view of all CAS activity during a defined time window: requests submitted, requests approved, requests denied (with denial reason), attacks executed, and BDA outcomes. Filtered by JTAC, by aircraft type, by target category, or by geographic area, the log surfaces patterns that are invisible in voice-only records — which approval steps take longest, which ROE categories generate the most override requests, which target types have the highest miss rates.
Timeline reconstruction for debrief uses the sortie record's timestamped state transitions to generate an event timeline that can be overlaid on the COP track history. The debrief audience can step through the sortie second by second: when the 9-line was submitted, when the kill box appeared on the COP, when friendly forces were inside versus outside the box, when clearance was granted, and when BDA was recorded. This reconstruction capability — impossible with voice-only records — transforms the post-mission debrief from a memory exercise into an evidence-based review.
The archived 9-line records also constitute the primary evidence base for LOAC compliance audits. If a post-strike investigation raises questions about whether the correct target was engaged, whether friendly force positions were correctly reported, or whether the approving authority saw the relevant COP state at the time of clearance, every answer is in the archive. The immutability of the audit log — enforced at the storage layer, not just at the application layer — ensures that the record cannot be altered after the fact to obscure accountability.