Intel Academy · Contents · Chapter 9 · §9.4 · Nederlandse versie

§9.4 Step 4: breakthrough COAs and decision support

From threat picture to decision: which COA breaks the net open, and how do you recognize that it's working?

Open §9.4 in the academy

Applying §7.3.5 (SEAD/DEAD & the ATO cycle) and §7.3.6 (third-party targeting).

MLCOA vs. MDCOA for Kaskilva

MLCOA: Kaskilva keeps most SAM batteries "silent" — radars off, engaging on cues from the fusion node and the long-range radars — to avoid early SEAD detection (compare the defensive perspective in airdefense-academy §5.11). MDCOA: at the first signs of an approaching strike package, Kaskilva activates the full network, including point defense around the airfields.

Because the batteries may be operating "silent", the threat ring on the Step 2 overlay is a floor, not a certainty: as long as the fusion node functions, the threat reaches as far as the network, not a single radar (§7.3.6). The friendly COA must therefore not only use the "gap" from Step 2, but prioritize the fusion node itself as the first target.

Friendly COA: layered SEAD/DEAD breakthrough

1) EW and anti-radiation weapons target the GCI fusion node (the HVT from Step 3) — if successful, the network falls back to isolated, less coordinated batteries. 2) The strike package flies the low corridor from Step 2, during the reduced-visibility window. 3) Timing is synchronized with the ATO cycle: the SEAD wave must fall within the strike package's ATO time slot.

Decision pointTriggerDecision
DP-1ELINT detects active fusion-node emission despite the SEAD waveRe-strike the fusion node before the strike package launches
DP-2Radar activity from a LOMEZ battery within 5 minutes of SEADMDCOA becomes likely — strike package is rerouted further north
Closing the loop

This case study runs in four steps through what Chapters 4 through 7 treat separately: the battlespace geometry determines what you map (Step 1), the combined threat overlay shows where the room is (Step 2), the kill-web analysis of the ORBAT points to which node matters (Step 3), and the COA/decision-support layer ties it all to an executable decision (Step 4). As with any IPB, this remains a living product: every new observation feeds back into Steps 2 and 3.