By Part 3 of the loop, sensors have detected, fusion has tracked, and operators have ranked candidates in front of them. The target stage begins: which of the candidates is worth engaging, with what priority, under what conditions, with what resources. This is where AI in defense is least mature, most controversial, and most likely to disappoint when over-promised. Part 3 is about doing it credibly — building decision-support tools that compress analyst cognition without crossing into autonomous targeting, with the structural human-in-the-loop boundaries that procurement and doctrine require.

The architectural framing remains Part 1: The Loop. The sensor-side engineering is in Part 2. This part covers the middle of the loop.

What Decision-Support AI Is and Is Not

The phrase "decision-support AI" is broad enough to cover both useful capabilities and dangerous overreach. The useful interpretation: AI that helps analysts and commanders process more information, evaluate more options, and act faster — while the decision itself remains theirs. The dangerous interpretation: AI that recommends actions in a way that operators accept without independent evaluation, transferring de-facto authority from human to model.

The structural pattern that distinguishes the two:

  • Useful decision support surfaces evidence, ranks candidates, computes consequences, and presents alternatives. The operator sees the analytical work but performs the judgment.
  • Dangerous decision support presents a single recommendation with high confidence and minimal exposed reasoning, encouraging operator acceptance without scrutiny.

The engineering implication: build tools that show their work. Confidence scores, contributing evidence, alternative interpretations, sensitivity to inputs. Every recommendation comes with the question "what would change if input X were different" answerable from the UI. Operators retain authority; the platform retains transparency.

The flagship decision-support capability in modern C2 is the ranked candidate list — sometimes called a target-of-interest list, recommended-engagement list, or threat-prioritization output depending on doctrine. The AI ranks tracks by composite score and presents the top N to operators.

The composite score blends multiple inputs: track confidence, identity certainty, threat-priority taxonomy match, operational context (within engagement zone, within commander's intent, within ROE), engagement feasibility (effector availability, geometry, timing), and collateral-risk factors. Each input is a separate signal computed by a separate subsystem; the ranking model combines them into a score.

The engineering rules that distinguish operational implementations from demo implementations:

Score decomposition. The operator can drill into any candidate's score and see how each component contributed. A high score is not an instruction — it is a starting point for the operator's review. If the operator dismisses a candidate, the dismissal feeds back to the ranking model with the operator's reasoning if provided.

Configurable weighting. Operators (within authorization) can adjust the relative weight of input signals — more weight on identity certainty for ambiguous environments, more weight on threat priority during specific operations. Defaults are role-appropriate; overrides are logged.

Stale-track filtering. Tracks whose lifecycle state is fading or lost (see Building a C2 System, Part 2) are excluded from the candidate list or visibly flagged. A confident engagement against a 90-second-old track is the kind of failure mode that procurement evaluators specifically look for.

Negative results visible. The list shows what was considered and rejected, not just the top N. If an operator wonders why a particular track did not surface, the answer is in the platform, not opaque.

Course-of-Action Analysis

Course-of-action (COA) analysis at the staff-officer level has historically been a labor-intensive process — planners propose options, evaluators simulate consequences, commanders pick. AI can compress every stage.

Option generation. Given a current operational picture, generate candidate courses of action. Constraints (terrain, ROE, available forces, time horizon) bound the search space. The output is a small number of distinct options with rough resource requirements.

Simulation and evaluation. For each candidate COA, simulate outcomes against plausible adversary responses. Monte Carlo over the uncertainty produces a distribution of expected results. The simulator's fidelity matters more than its volume — a coarse simulator that captures the right uncertainties beats a high-fidelity simulator that misses the strategic dimensions.

Comparison and recommendation. Rank COAs against multiple criteria (mission success probability, casualty estimates, time-to-completion, logistics burden, sustainability). The recommendation is one perspective; the commander's evaluation is another. The platform surfaces both.

The operational reality: COA AI is at the pilot stage in 2026. The simulators are partially validated; the LLM-augmented option generation is impressive in demos and inconsistent in operations; the staff workflow integration is bespoke for each platform. The capability is mature enough to use, immature enough to require structured evaluation. The honest market view is in AI Defence Market Landscape 2025.

LLMs in Defense Decision Support

Large Language Models have moved from experimental to operational in narrow analyst-facing workflows since 2023. The credibly deployed uses in 2026:

Drafting situation reports from structured input. The LLM converts a set of track changes, intelligence summaries, and operational events into a coherent narrative. The analyst reviews and confirms before publication. Faster than manual drafting; the analyst's judgment governs publication.

Summarizing intelligence products. Multi-source intelligence collections (cables, briefings, OSINT, partner-CSIRT bulletins) summarized into briefing-ready outputs. The same review-before-publication pattern applies.

Natural-language querying of intelligence stores. The analyst types a question; the LLM translates it into a structured query against the data store; results return with the source chain. The query becomes auditable, the response is grounded in citable sources.

Translation across coalition languages. Domain-specific translation for defense terminology. The output is checked, not blindly accepted.

The pattern that distinguishes operational LLM use from speculative LLM use:

  • Retrieval-augmented generation grounded in vetted corpora — the LLM cannot say something it cannot cite from the corpus.
  • Citation requirement — every output line traces back to source material. Operators can verify before relying.
  • Hard upper bound on operational latitude — the LLM cannot author taskings, classifications, or other operational actions. It produces text for human review.
  • Audit trail for every generated artefact — what prompt, what model, what corpus, what timestamp, what reviewer.
  • Adversarial-input awareness — prompt injection, jailbreak attempts, deliberate misdirection. Defenses must be built in.

The detailed engineering treatment is in LLMs in Intelligence Triage for Defense.

Key insight: LLM hallucination in a customer-service context is an embarrassment. In a defense context it can be a strategic incident. The defensive engineering is structural: retrieval-augmented generation, citation requirements, restricted operational scope, audit trails. Any LLM deployment without these is a procurement risk; any with them is a meaningful capability multiplier.

Pattern-of-Life and Anomaly Detection

The Decide stage benefits enormously from background context. Knowing that a particular vessel always calls at three specific ports, then suddenly diverts to a fourth, is high-grade decision-support information. AI-driven pattern-of-life analysis surfaces this context automatically.

The pattern: ingest longitudinal track data over months or years; segment into routine behaviors per entity; score new observations against the routine baseline; surface deviations to operators. The hard part is not the algorithm — Gaussian mixtures, hidden Markov models, gradient-boosted classifiers all work — but the data curation, the operational definition of "anomalous", and the ethics review around behavioral profiling. The detailed treatment is in Pattern-of-Life Analysis in Military Intelligence.

The operational value lies in the ranking — not the surfacing of anomalies (which are common and mostly benign) but the prioritization that puts the few that matter at the top of the analyst's queue. A PoL system that surfaces 200 anomalies an hour is unusable; one that ranks the top five and explains why is irreplaceable.

Operator UX: Where the AI Lives in the Workflow

Decision-support AI lives inside an operator workflow. If the AI requires the operator to leave the COP, open a separate tool, and re-context their thinking, the AI loses. The integration must be in-workflow, in-context, in-band with the operator's existing pattern.

The patterns that work in practice:

Inline annotations on the COP. AI-derived attributes — confidence score, recommended priority, detected anomaly — render as symbol modifiers on the existing COP display. The operator's eye is already there.

Drill-down panels. A click on any AI-generated annotation opens a panel showing the underlying evidence: input track data, model confidence breakdown, source signals. The operator can confirm or dismiss with full information.

Workflow-embedded recommendations. When the operator is composing a tasking order, the AI surfaces relevant historical patterns. When the operator is reviewing a candidate engagement, the AI surfaces collateral-risk factors. The AI is present where the cognitive work is, not in a separate tab.

Explicit consent gates. Where the AI's recommendation crosses a threshold (a new engagement, an escalation, an action with operational consequence), the gate is explicit and visible. The operator confirms; the platform records.

The broader operator-UX principles for defense software, including the ruggedized-environment realities, are in Ruggedized UX for Military Operators.

Accreditation Implications

Decision-support AI is harder to accredit than sensor-side AI. The reason is the proximity to consequential decisions. An accreditation reviewer will ask: under what conditions could this tool mislead an operator into an action they would not otherwise take? What evidence demonstrates that operators retain effective judgment when this tool is active?

The evidence that accreditation reviewers find credible:

  • Operator-in-the-loop test results showing realistic mission scenarios with the tool active and the tool absent, comparing decision quality.
  • Bias audits — does the tool systematically favor certain target types, certain geographies, certain identity attributes?
  • Adversarial-robustness evaluation — what happens under deliberate manipulation of the inputs?
  • Failure-mode analysis — what does the tool do under model drift, sensor degradation, or out-of-distribution inputs?
  • Drift monitoring in operational deployment — quantitative evidence the tool's behavior remains within the accredited envelope.

The procurement-grade discipline of generating this evidence as a side effect of the development pipeline is in DevSecOps for Defense Pipelines. The broader NATO AI strategy framing of these requirements is in NATO's AI Strategy for Defense Software.

What's Next

Part 3 has covered the target-stage AI. Candidate lists, course-of-action analysis, LLM-augmented analyst tooling, pattern-of-life as background context, operator-UX integration, accreditation requirements. The platform now produces decision-support output that operators can use without losing judgment.

Part 4 closes the loop. How AI participates in engage and assess without crossing the autonomous-effects line, the structural HITL boundaries coded into the platform, the doctrine and procurement realities that pin the boundary in place, and where the engineering meets international humanitarian law.