The Automated Kill Chain: From Detection to Engagement in Seconds

Full report

On this page

Experience thesis and evidence discipline

Experience title: “90 Seconds: Human Command Versus Machine-Speed Warfare”

The experience is a public-facing, non-operational simulation of defensive decision-making. It shows how a sequence that once depended on personnel manually receiving reports, reconciling contradictions, communicating with commanders, and directing a weapon can be compressed when sensors, data fusion, classification, prioritization, and response logic are connected electronically.

Its central argument is not that an artificial intelligence “understands” a battle. The machine has no inherent conception of intent, surrender, civilian status, proportionality, or the political meaning of an action. It receives signals, associates observations, estimates states, assigns scores, applies constraints, and issues or recommends predefined outputs. What appears to be a two-second decision is therefore the visible end of a much longer chain of human engineering, policy, legal, command, testing, and configuration decisions.

Traditional U.S. targeting literature commonly describes the F2T2EA sequence as Find, Fix, Track, Target, Engage, Assess, with the early stages relying heavily on intelligence, surveillance, and reconnaissance and the targeting and engagement stages requiring substantial decision-making and force coordination. This experience expands “Target” into Identify, Prioritize, and Authorize so that visitors can see the normally hidden judgments inside that single word.

The experience must distinguish five evidence categories at all times:

This discipline is especially important because words such as automated, autonomous, and AI-enabled are not interchangeable. Under U.S. Department of Defense policy, an autonomous weapon is one that, once activated, can select and engage targets without further operator intervention; a semi-autonomous weapon engages targets or target groups selected by an operator, although automated functions may acquire, track, identify, cue, prioritize, time firing, or provide terminal guidance. The ICRC uses a broader functional framing in which a system, after activation, selects and applies force on the basis of sensor information and a generalized target profile without a human choosing the specific target at the moment of force.

The experience therefore avoids unsupported statements such as “the AI decided to attack.” Its interface instead uses precise language:

Sensors produced observations. A fusion system associated them with a track. A classifier assigned category scores. A priority function ranked the track. A rule set found that preauthorized conditions were satisfied. An effector executed the previously permitted response.

All geography, forces, timing, confidence values, target categories, and engagement criteria below are fictional. They are deliberately abstracted and are not calibrated to any real defense system.

System architecture and kill-chain diagram

The visitor initially sees the kill chain as a single bright line. Selecting “Reveal the machinery” expands it into a network of sensors, models, rules, communications, operators, and effectors. This is the first major lesson: speed comes less from a single brilliant algorithm than from eliminating handoffs and connecting specialized components.

flowchart LR
    subgraph P["Human decisions made before the event"]
        P1["Mission objective"]
        P2["Approved object or threat categories"]
        P3["Geographic boundaries"]
        P4["Confidence and evidence thresholds"]
        P5["Operating time window"]
        P6["Rules of engagement and legal review"]
        P7["Abort, defer, override, and shutdown conditions"]
    end

    P --> E["Authorized operating envelope"]

    subgraph L["Live defensive loop"]
        S["Sensors\nradar • infrared • visual • acoustic • electronic • network"]
        F["FIND\nDetect returns, signals, or anomalies"]
        X["FIX\nEstimate position, motion, and observation quality"]
        T["TRACK\nAssociate reports with persistent tracks"]
        I["IDENTIFY\nAssign category probabilities and unknown status"]
        R["PRIORITIZE\nRank urgency, predicted consequence, and time available"]
        A{"AUTHORIZE\nHuman approval or prior authorization?"}
        G["ENGAGE\nApproved defensive effector acts"]
        B["ASSESS\nEstimate outcome, residual threat, and uncertainty"]
    end

    S --> F --> X --> T --> I --> R --> A --> G --> B
    B --> T
    B --> S
    E --> I
    E --> R
    E --> A

    U["Uncertainty ledger\nsensor quality • disagreement • missing data • model limits"]
    U -.-> X
    U -.-> T
    U -.-> I
    U -.-> R
    U -.-> A

    H["Human control points\nconfigure • approve • supervise • override • deactivate • review"]
    H -.-> E
    H -.-> A
    H -.-> G
    H -.-> B

Find

Sensors do not ordinarily report “hostile drone” as an established fact. They produce measurements: a radar return with range and velocity; infrared contrast against a background; pixels or an extracted shape; an acoustic pattern; an electronic emission; or a network message whose origin and authenticity may be uncertain.

Detection algorithms decide that a signal is sufficiently different from noise or background behavior to create a tentative object or event. Lowering the detection threshold can reveal weak threats earlier but increases clutter and false alerts. Raising it reduces clutter but may delay or miss faint objects.

Fix

“Fix” estimates where the object is and how reliable that estimate is. A display should represent this as a region of uncertainty, not a perfectly precise icon. The region may shrink as observations accumulate or widen when a sensor loses contact, weather interferes, or reports disagree.

Track

Tracking attempts to determine which observations belong to the same object over time. This is an association problem, not merely a drawing problem. Closely spaced objects, crossing paths, intermittent detections, decoys, and sensor latency can cause one track to split, two tracks to merge, or identities to swap.

Identify

Identification produces competing hypotheses, such as:

• uncrewed aerial object: 0.74
• civilian survey aircraft: 0.13
• bird group or environmental clutter: 0.08
• unknown: 0.05

The interface must never translate such a score into “74 percent certain that this is hostile.” A model score is conditional on the model, its data, its calibration, the available sensor inputs, and the categories designers allowed it to express. It is neither legal judgment nor ground truth. NIST guidance emphasizes communicating how and why an AI system produced a prediction or recommendation, because explainability supports monitoring, debugging, documentation, audit, and governance.

Prioritize

Prioritization ranks tracks using programmed considerations such as predicted time to a protected boundary, potential consequence, track quality, object behavior, available defensive resources, and whether another sensor can resolve uncertainty before action is required.

A rank is not an ethical judgment. It is the output of a scoring rule whose weights and constraints were selected earlier. The visitor can inspect those weights but cannot enter real tactical values.

Authorize

Authorization is the main point of divergence among the three modes:

• In human-directed mode, personnel review and authorize each engagement.
• In AI-assisted mode, the system fuses and ranks evidence but waits for a human decision.
• In preauthorized-automation mode, a prior human authorization permits action when a narrowly defined set of conditions is satisfied.

U.S. DoD policy requires autonomous and semi-autonomous weapon systems to permit appropriate levels of human judgment over force, to undergo rigorous verification, validation, and realistic testing, and to provide trained operators with understandable interfaces and clear activation and deactivation procedures. The policy also connects system operation to applicable law, safety rules, and rules of engagement. These are policy requirements, not proof that every conceivable automated system is safe or lawful.

Engage

The effector is shown abstractly as an approved defensive response, avoiding weapon-employment procedures. Depending on the educational branch, the effect can be a warning, electronic disruption, interception, containment, or no action. The important distinction is between selecting a response and physically executing it: both can be automated, but they are separate functions.

Assess

Assessment determines whether the intended outcome occurred, whether the track persists, whether a second action is needed, and whether previously harmless objects were affected. Assessment is also probabilistic. A disappearing radar return could indicate successful interception, sensor masking, track loss, fragmentation, or a target maneuver.

Assessment feeds back into the chain. An erroneous “threat remains” conclusion can trigger unnecessary re-engagement; an erroneous “threat removed” conclusion can leave a continuing danger unaddressed. The experience therefore displays assessment confidence separately from identification confidence.

Scene-by-scene interactive narrative

The fictional setting is the Morrow Strait, part of the invented Pelagos Maritime Region. The Asteria Maritime Guard is protecting a humanitarian shipping corridor and the unmanned Kestrel Relay Platform during a scheduled ninety-second high-alert window. There are no real coordinates, installations, organizations, target lists, procedures, or calibrated system values.

Six fictional objects enter or approach the sensor field:

The simulation runs all three command modes simultaneously. The left, center, and right panels receive the same underlying event stream; only information processing and authority allocation differ.

Audio reinforces uncertainty. A single clean alert tone is reserved for constraint satisfaction, not “truth.” Conflicting observations produce overlapping, quieter tones. Human-directed mode includes voices, acknowledgments, and repeated read-backs; AI-assisted mode replaces much of this with a recommendation card; preauthorized mode is initially almost silent, making its speed feel efficient but also unsettling.

Mode comparisons and user-controlled branches

All numerical values in this section are fictional teaching values. They are not modeled on, derived from, or intended to estimate the performance of any real military system. The same six-object scenario and underlying sensor stream are used in each mode.

Runtime comparison

These numbers are designed to prevent simplistic conclusions. The human-directed mode is slower but not automatically safer: overload, communications delay, and hurried interpretation can create mistakes. Preauthorized automation is faster but not automatically more accurate: it may act consistently on an incorrect track, bad data, or a badly designed permission. AI assistance can reduce search and correlation workload while introducing automation bias, in which a polished recommendation receives more trust than its evidence warrants.

The interface always shows model confidence, sensor agreement, evidence completeness, and time remaining as separate measures. A high confidence score with only one functioning sensor should look different from the same score supported by independent observations.

Authority allocation comparison

The table’s key idea is that less human intervention at the final second can mean more—not less—importance for earlier human decisions. The permitted target categories, geographic and temporal limits, operating assumptions, sensor requirements, confidence boundary, abort logic, and supervisory design become proxies for case-by-case judgment.

This is consistent with the types of control measures emphasized in public policy discussions. U.S. DoD policy addresses understandable human-machine interfaces, clear activation and deactivation, realistic testing, resistance to spoofing, and appropriate human judgment; the ICRC recommends limits on target types, duration, geographic scope, scale, situations of use, and requirements for supervision, intervention, and deactivation.

Response to uncertainty and failure

Public U.S. policy explicitly recognizes failures arising from software errors, human-machine interaction, communication degradation, cyberattack, jamming, spoofing, decoys, and unforeseen operational states. It calls for realistic testing, monitoring when systems or environments change, resilient design, operator training, and understandable controls.

User interactions and branching decisions

The visitor can modify only abstract, fictional settings. No interaction exposes real engagement distances, sensor performance, firing doctrine, vulnerabilities, or system-specific procedures.

• Set the authorization model. Choose case-by-case human approval, human approval after an AI recommendation, or prior authorization within a restricted envelope.
• Change the confidence boundary. Compare lower, medium, and higher abstract thresholds while observing missed-threat and false-positive consequences.
• Require independent evidence. Select one-source detection, two-sensor agreement, or two-sensor agreement plus authenticated cooperative identification.
• Resize the fictional defensive boundary. A wider boundary provides more time but includes more innocent traffic; a narrow boundary reduces exposure but leaves less time for correction.
• Select allowable object categories. The interface warns when a category is broad, poorly defined, or difficult for available sensors to distinguish.
• Set the operating window. Authorization expires visibly rather than remaining indefinite.
• Program abort conditions. Options include sensor disagreement, loss of track quality, civilian entry, loss of supervisory link, geofence exit, expired authorization, or inability to assess consequences.
• Introduce communications latency. The visitor sees that contextual messages and human approval may travel more slowly than local sensor processing.
• Inject degraded conditions. Sea clutter, glare, weather, sensor dropout, spoofed emissions, delayed reports, crossing tracks, and saturation can be introduced individually or together.
• Inspect rather than act. Freeze the chain, open source reports, compare hypotheses, and see how much of the ninety-second window is consumed.
• Challenge the recommendation. In AI-assisted mode, the visitor can reject a high-confidence recommendation and must state which contradictory evidence justified the rejection.
• Suspend automation. In preauthorized mode, the visitor can switch to observation-only or human approval, but the interface shows whether sufficient intervention time actually remains.
• Run a counterfactual. Change one prior rule while holding every sensor observation constant, making the causal effect of earlier human choices visible.

Important branches include correct engagement, correct abstention, delayed defense, missed threat, false positive, automatic abort, escalation to human review, authorization expiry, and indeterminate assessment. The debrief does not assign one universal score. Instead, it evaluates speed, evidence use, compliance with the fictional authorization envelope, avoidable exposure, and the visitor’s handling of uncertainty.

“What the Machine Saw” replay

The replay rejects the conventional cinematic “robot vision” display in which a computer instantly boxes an object and labels it HOSTILE. It reconstructs the event through seven partial perspectives, followed by a counterfactual view.

Radar perspective

The screen shows returns, estimated range-rate, observation age, clutter likelihood, and uncertainty. Amber One initially appears as a weak moving return. Amber Three intermittently separates into several returns. Amber One and Amber Two approach one another in the display, producing competing track-association hypotheses.

The educational caption reads:

Radar measured reflected energy and motion-related features. It did not observe intent, legal status, or mission.

Infrared and visual perspective

The visitor sees contrast, glare, cloud obstruction, changing aspect, and incomplete silhouettes. Instead of a clean object photograph, frames contain blur and missing data. Amber Two looks superficially similar to Amber One from one angle; the rescue helicopter becomes distinguishable only after another observation arrives.

The caption reads:

The imaging system compared patterns with learned or engineered features. Similar appearance is evidence, not identity.

Electronic and network perspective

Amber Four generates an intermittent emitter pattern that resembles one element associated with Amber One. The network panel separately receives a delayed cooperative-identification message for Amber Two and a delayed routing notice for Amber Five.

The visitor can toggle arrival time versus event time. This shows that a report generated earlier can reach the decision system after a local rule has already evaluated the track.

The caption reads:

Information can be authentic but late, timely but false, or technically valid yet attached to the wrong track.

Acoustic perspective

A weak periodic signature is embedded in wind and machinery noise. The classifier alternates among several hypotheses. The acoustic sensor contributes modestly to the fused estimate rather than “voting” with equal authority.

The caption reads:

Fusion is not simple majority rule. Sensor relevance and reliability vary with context.

Fused-model perspective

The viewer sees a track graph rather than a single icon. Each observation is connected to one or more possible tracks, with edge weights representing association strength. The model maintains multiple possibilities:

• Amber One and Amber Two remain separate.
• Two observations have been exchanged between their tracks.
• One of the detections is clutter.
• Amber One temporarily split into two tracks.

As reports arrive, the probabilities change. A confidence-history graph reveals whether the final score accumulated gradually, jumped because of one influential sensor, or remained high despite substantial missing evidence.

The interface must expose at least four distinct questions:

1. What category did the model score highest?
2. How well supported was the track association?
3. How complete and trustworthy were the inputs?
4. Was the model operating in conditions represented during testing?

NIST’s AI risk guidance supports continuous monitoring for performance degradation, adversarial attacks, unusual behavior, near misses, and changing deployment conditions. It also recommends override, incident-response, change-management, and decommissioning mechanisms when systems exceed risk tolerances.

Human-operator perspective

The display adds everything the fusion view omitted: multiple alert windows, communications traffic, a second uncertain track, status messages, a countdown, an incomplete routing update, and responsibility for the consequences.

In human-directed mode, the visitor sees forty-six reports distributed across several screens and channels. Some are redundant, some conflict, and some arrive out of order. The experience shows why “put a human in the loop” is not sufficient by itself. A nominal approval step may provide little meaningful control if information is unintelligible, workload is excessive, the time window is shorter than human reaction and communication time, or the interface encourages blind acceptance.

In AI-assisted mode, most reports collapse into a recommendation card:

Recommended response: defensive intercept

Classification score: 0.91

Primary reason: predicted entry into protected area

Contradictory evidence: possible cooperative-ID association unresolved

Time to decision boundary: 9 seconds

Alternatives: defer for another observation; suspend; observe only

The recommendation is intentionally persuasive-looking. The user can toggle “Hide uncertainty warnings” and observe how quickly people begin to treat the score as a fact, illustrating interface-driven automation bias.

Final rule-set perspective

The cinematic display disappears. The visitor sees that the “decision” in preauthorized mode is a constraint evaluation:

PERMISSION EXISTS
AND authorization has not expired
AND track remains inside the fictional defensive boundary
AND predicted path enters the protected area
AND highest-scored category is within the approved set
AND category score meets the configured boundary
AND independent-evidence requirement is satisfied
AND track quality is sufficient
AND no authenticated protected-object identifier is associated
AND no civilian-exclusion or abort condition is active
AND supervisory status permits automated action
THEN execute the approved defensive response
ELSE abstain, continue observing, or escalate

This is not proposed operational software and contains no real values. Its function is to show that automated action is the conjunction of earlier human choices. Changing a single term can alter the result even though the sensor data and model output are identical.

The rule view also distinguishes three failure classes:

• Perception failure: the sensor or model represents the world incorrectly.
• Specification failure: the system does exactly what was programmed, but the programmed rule does not express the commanders’ or legal reviewers’ true intent.
• Authority failure: the rule may function technically, but the authorization is invalid, expired, overly broad, or applied outside the approved context.

Counterfactual replay

The final replay places two timelines side by side.

In the first, Amber Two’s valid civilian identifier arrives 0.4 seconds before the automation rule is satisfied. The abort condition activates and the system abstains.

In the second, the message is delayed by two additional seconds. The local system sees exactly the same earlier sensor evidence but acts before the contextual message arrives.

The interface asks:

Did the classifier change? No.

Did the rule change? No.

Did the world change? No.

What changed? Information latency relative to the action window.

The lesson is that machine speed can outrun not only human thought, but also the communications needed to supply context. A design that ignores that asymmetry can be internally consistent and still produce an unacceptable result.

Public defensive-automation examples

These examples demonstrate real, publicly described forms of defensive automation. They do not establish that every configuration acts without human approval, that public descriptions reveal actual wartime settings, or that any system is safe or lawful in every environment.

Phalanx close-in weapon system

Verified public fact: The U.S. Navy describes the Mk 15 Phalanx as a fast-reaction, radar-guided point-defense system. Its public fact file states that it can automatically detect, evaluate, track, engage, and perform kill assessment against certain threats; the Block 1B variant adds an electro-optical sensor.

Government claim: The Navy calls Phalanx the only deployed close-in weapon system capable of autonomously performing its own search, detection, evaluation, tracking, engagement, and kill-assessment functions. This is significant public evidence of an automated detect-through-assess defensive sequence, but it remains an official characterization rather than public disclosure of every operational condition.

Analyst interpretation: Phalanx is an effective educational example of authority moving earlier. In a rapidly developing point-defense event, the consequential human choices may include whether to activate an automatic mode, what defense sector and status apply, and when to supervise, inhibit, or deactivate—rather than manually commanding each mechanical step.

Unknown or non-public: The cited fact file does not provide current ship-specific activation criteria, identification thresholds, exact modes in particular operations, rules of engagement, crew actions, software, countermeasure performance, or detailed safeguards. The experience must not invent them.

Aegis weapon system

Verified public fact: The Navy publicly characterizes Aegis as a centralized, automated command-and-control and weapons-control system designed around a detection-to-engagement architecture. Its public description says the SPY radar automatically detects and tracks while simultaneously performing search, tracking, and missile-guidance functions.

Government claim: Public Navy descriptions emphasize simultaneous multi-target processing and integrated command-and-decision functions. Such claims establish extensive automation in sensing, tracking, and weapons coordination; they do not, by themselves, prove that final engagement is autonomous in every mission, mode, or configuration.

Analyst interpretation: Aegis illustrates how compression can occur through system integration. Radar observations need not be manually transcribed into separate tracking, command, and guidance systems. The relevant gain is not simply “AI speed”; it is reduced latency between components.

Unknown or non-public: Public fact files do not disclose the full decision logic, current automation settings, engagement doctrine, threat-specific thresholds, crew permissions, network behavior under combat conditions, or classified capabilities. The interactive experience should therefore represent Aegis only at a high architectural level.

Iron Dome

Manufacturer claim: Rafael publicly describes Iron Dome as combining radar, battle-management and command-and-control functions, and Tamir interceptors. The company states that the system predicts which threats are headed toward defended areas and selectively responds to those threats while avoiding launches against trajectories projected into open areas or the sea.

Verified public fact: It is publicly documented that selective trajectory assessment is central to the system’s stated design. However, performance rates and broad effectiveness statements on the manufacturer’s site remain manufacturer claims rather than independent validation.

Analyst interpretation: The example demonstrates that classification need not mean “what exact object is this?” It may instead concern predicted consequence: Will this trajectory enter the predefined defended zone? That prediction can prioritize limited defensive resources and filter objects that do not satisfy the response rule.

Unknown or non-public: The cited material does not reliably establish the exact role of human authorization in every operational setting, the thresholds for trajectory or impact prediction, override arrangements, detailed engagement logic, or current rules of engagement. The experience must not describe Iron Dome as universally or fully autonomous on this evidence.

Counter-rocket, artillery, and mortar defense

Verified public fact: Public U.S. Army descriptions characterize counter-rocket, artillery, and mortar defense as a system of systems integrating sensing, warning, command and control, response, and interception functions. This architecture demonstrates that automation can protect people not only by engaging an incoming object, but also by rapidly generating warning and cueing information.

Government claim: Army descriptions state that such systems detect launches, warn threatened areas, and support interception. As with other official descriptions, this establishes publicly claimed functional integration but not every deployment-specific sequence or authority arrangement.

Analyst interpretation: Counter-rocket defense is a useful case because the time available may be extremely short. A human may have meaningful control mainly through prior siting, defended-area definitions, activation decisions, operating status, and abort or inhibition rules. Warning dissemination itself may appropriately be more automated than an application of force.

Unknown or non-public: Public summaries do not reveal current operational thresholds, sensor placements, specific defended locations, detailed timing, failure rates, or local engagement procedures. None should be reconstructed in the experience.

Low-Slow-Small UAS Integrated Defeat System

Verified public fact: A U.S. Army public description of LIDS identifies a modular collection of command-and-control, electronic-warfare, electro-optical and infrared, direction-finding, radar, radio, gun, and interceptor components. It says Forward Area Air Defense Command and Control supplies situational awareness and automated air-track information.

Government description of human role: The same Army account states that passive and active sensors detect, track, and identify uncrewed and non-hostile aircraft, while an operator tasks an appropriate mitigation technique. This is an important counterexample to the assumption that extensive sensing and correlation automation necessarily implies autonomous final engagement.

A 2025 Army account of the Red Sands counter-UAS exercise describes combined command-and-control personnel correlating radar, electro-optical, and infrared feeds; crews controlling fires; operators executing commands; and planners establishing engagement sectors, control statuses, procedures, and priorities before live operations. It stresses the importance of understanding system capabilities and limitations to avoid over-engagement or failure to engage.

Analyst interpretation: LIDS provides a strong real-world analogue for the AI-assisted panel: machines collect and organize tracks, but operators retain responsibility for selecting among response options. It also shows that procedures, training, common displays, and communications can be as important as the classifier.

Unknown or non-public: Public descriptions do not establish every current configuration, software feature, recognition capability, deployment status, authorization rule, or classified performance characteristic.

What these examples do and do not prove

Together, the examples verify that defensive systems can automate substantial portions of detection, tracking, correlation, trajectory prediction, prioritization, cueing, engagement execution, and assessment. They do not support the sweeping claim that contemporary defensive systems all make independent lethal decisions, that “AI” controls them end to end, or that human involvement has disappeared.

The stronger public conclusion is narrower: different systems automate different functions, under different modes and authority structures. A system may be highly automated in sensing and tracking but require human response selection. Another may be capable of an automatic local point-defense sequence after activation. A larger combat system may integrate automated tracking and weapons coordination while leaving engagement authority dependent on doctrine, settings, and circumstances.

Failure, uncertainty, safeguards, and human control

Automation can reduce some errors while concentrating others. A human team may inconsistently process dozens of reports; an automated system can process them consistently, but a common software, data, or configuration error can affect every track at machine speed.

Failure and uncertainty scenarios

Track swap. Two objects cross, and a valid civilian identifier becomes associated with the wrong track. The system may confidently label the dangerous object as protected and the benign object as threatening. The appropriate interface response is to preserve competing associations, visibly lower track confidence, and escalate when identity depends on an unstable association.

Unknown civilian object. A rare civilian vehicle or unusual flight pattern is poorly represented in the model’s training or test data. If the classifier must choose among only known military categories, it may produce a misleadingly high score. The safer design includes an explicit unknown or out-of-distribution state and treats unfamiliarity as a reason to abstain, not as positive evidence of hostility.

Spoofing and deceptive signatures. An adversary may imitate cooperative identifiers, electronic emissions, motion patterns, or other expected features. Conversely, benign equipment may coincidentally resemble a threat signature. Public U.S. policy specifically calls for resilience against adversarial attacks and spoofing, as well as cybersecurity and anti-tamper protections.

Weather, glare, and maritime clutter. Sensors can fail differently under environmental conditions. Fusion helps only when uncertainty and dependence are modeled correctly. Two sensors influenced by the same environmental phenomenon are not necessarily two independent confirmations.

Communications delay or loss. The local system may have current kinematic information while the human command element has richer but older context. Preauthorizing operation during a communications outage is itself a consequential human decision; loss of communication should not silently expand authority.

Automation bias. Operators may accept a confident recommendation despite contradictory evidence, especially when the interface makes the automated answer easier to approve than to investigate. Meaningful human control requires sufficient time, information, competence, and interface support—not merely a confirmation button.

Threshold cliff. Nearly identical scores on opposite sides of a decision threshold can produce radically different actions. The experience lets visitors add an uncertainty band in which the system abstains or requests human review rather than treating a single decimal boundary as a natural fact.

Model and environmental drift. Sensor characteristics, software, adversary tactics, civilian traffic, or environmental conditions can change after testing. NIST recommends ongoing monitoring for drift, degradation, adversarial behavior, near misses, and unexpected impacts, while U.S. DoD policy calls for additional testing when changes in design or operating environment may affect confidence in safe performance.

Saturation and priority starvation. A large number of low-cost objects can consume sensors, communication bandwidth, interceptors, and operator attention. A prioritization system may efficiently process the wrong objective—for example, repeatedly servicing high-confidence decoys while a lower-confidence threat advances.

Assessment error. Sensor loss may be mistaken for successful defense, or debris may be interpreted as continuing targets. Repeated automatic engagement based on uncertain assessment can compound error. The system should distinguish “outcome confirmed,” “track lost,” and “result unknown.”

Configuration error. A geofence may be shifted, a time window may fail to expire, an approved category may be too broad, or an abort condition may be disabled during maintenance. Such errors are particularly dangerous because the machine may execute the mistaken instruction perfectly.

Context changes after authorization. Civilian traffic may enter an area that was empty when activation was approved. Weather may degrade identification. A protected facility may change status. Preauthorization should therefore be conditional and revocable rather than treated as a one-time permanent transfer of authority.

Layered safeguards

No individual safeguard guarantees acceptable behavior. The experience presents safety as a layered architecture in which independent controls can detect or contain different failure classes.

Mission-envelope safeguards constrain target or object categories, geography, duration, scale, operating situation, permissible effects, and resource use. Authorization automatically expires. Expansion of a boundary or category requires a deliberate mode change rather than an unnoticed configuration edit. The ICRC specifically recommends restrictions on target types, duration, geographic scope, scale, situations of use, and requirements for supervision and intervention.

Evidence safeguards include independent-sensor requirements, source authentication, data provenance, observation-age indicators, track-association confidence, explicit unknown categories, minimum track quality, and warnings when sensors share a common failure source. A numeric confidence threshold should never replace evidence-quality checks.

Decision-logic safeguards include abstention states, uncertainty bands, timeouts, hysteresis to prevent rapid oscillation, protected-object exclusions, dynamic civilian-exclusion conditions, resource limits, and rules that require escalation when inputs conflict. The logic should fail toward a defined restricted state rather than improvising outside its authorization.

Human-control safeguards include clear activation and deactivation, a prominent suspend function, understandable system-status feedback, visibility into what the machine will do next, and sufficient supervisory staffing. Changes to authorization mode, geographic scope, or approved categories should receive stronger control than routine display adjustments. U.S. policy requires trained operators to have understandable interfaces, transparent status feedback, and clear procedures for activating and deactivating autonomous functions.

Engineering safeguards include rigorous verification and validation; realistic developmental and operational testing; testing after consequential software, mission, target-set, or environmental changes; cybersecurity; anti-tamper measures; adversarial and spoofing tests; fault injection; calibration assessment; and red teaming. Public U.S. policy requires rigorous testing and emphasizes resilience in realistic environments, while NIST recommends testing in deployment-like conditions and regular post-deployment evaluation.

Operational safeguards include training in limitations as well as capabilities, rehearsed transition between automatic and manual modes, audit logs, recording of sensor and rule states, near-miss reporting, incident investigation, change control, and revalidation when the environment changes. Logs should preserve not merely the final score but the reports, model version, configuration, authorization, rule evaluation, operator actions, and timing that produced the outcome.

Legal and ethical safeguards include weapons reviews, mission-specific legal advice, rules of engagement, distinction between military objectives and civilian persons or objects, proportionality assessment, feasible precautions, target verification, and mechanisms to suspend or cancel action when the target or expected consequences change. IHL requires distinction and proportionality and calls for feasible precautions, including verification and cancellation or suspension when the object is not a lawful military objective or the attack appears disproportionate.

Institutional safeguards assign responsibility across the lifecycle. Designers are responsible for foreseeable technical limitations and truthful documentation; testers for realistic evaluation; procurers for requirements and acceptance; commanders for mission configuration and authority; operators for proper use and intervention; legal reviewers for applicable legal analysis; and political authorities for broader policy choices. Distributed responsibility should mean multiple accountable actors, not responsibility diluted until no one owns the result.

What meaningful human control requires

A human is not meaningfully “in the loop” merely because an interface displays an approval button. The visitor should be asked whether the operator:

• had enough time to understand the evidence;
• could distinguish model score from verified fact;
• knew which sensors were missing or unreliable;
• understood the consequences of approval and non-approval;
• possessed a practical ability to reject, suspend, or deactivate;
• was trained for the current conditions;
• was not overloaded by unrelated alerts;
• and was exercising authority that remained legally and operationally valid.

Likewise, a person supervising several automated systems may formally be “on the loop” but functionally unable to intervene before a two-second action. The system must therefore be evaluated in terms of actual intervention opportunity, not labels alone.

The deepest safeguard is to recognize where judgment cannot be adequately reduced to observable features and rules. A system should not be used merely because automation is technically possible. NIST’s risk framework explicitly advises considering non-AI, non-automated, and semi-automated alternatives and weighing benefits against negative risks throughout the system lifecycle.

Glossary and closing lesson

Automation The execution of a defined function by machinery or software according to designed logic. Automation may range from stabilizing a sensor and correlating tracks to executing a response sequence. An automated function is not necessarily adaptive, intelligent, or autonomous.

Autonomy A system property in which, after activation, the system selects among actions based on information from its environment without requiring a human to command each specific step. Autonomy is function- and context-specific: a platform can be autonomous in navigation but not in engagement, or autonomous in track selection while requiring human authorization for force. U.S. DoD policy distinguishes autonomous systems from semi-autonomous systems partly according to whether further operator intervention is required for target selection and engagement.

Preauthorization Human authorization granted in advance for a system to take a specified action when defined conditions are satisfied. It should state the permitted objective, categories, area, duration, evidence requirements, constraints, abort conditions, and supervisory arrangement. Preauthorization is not the absence of a human decision; it is a decision displaced in time and expressed as a permission envelope.

Sensor fusion The process of combining observations from one or more sensors to estimate a coherent object, track, event, or state. Fusion must account for timing, uncertainty, dependence, source reliability, and competing associations. It can reduce uncertainty, but it can also spread a mistaken association across an entire system.

Confidence threshold A configured boundary used to decide whether a model score is sufficient for a particular next step. It is not certainty, truth, hostility, legal targetability, proportionality, or moral permission. Its meaning depends on calibration, data quality, operating conditions, and the decision for which it was designed.

Human-in-the-loop An arrangement in which a human must make or approve the relevant engagement decision before the system can apply the approved effect. Meaningful control additionally requires time, information, understanding, authority, and a practical ability to reject the recommendation.

Human-on-the-loop An arrangement in which the system can act while a human supervises its behavior and can intervene, override, suspend, or terminate. The label is misleading when the action window is too short, communications are unreliable, or the operator supervises too many systems to intervene effectively. U.S. DoD terminology includes operator-supervised autonomous systems in which operators can intervene and terminate engagements.

Human-out-of-the-loop An arrangement in which no human intervention is expected or practically available during the particular machine decision and action window. Humans may still have designed, tested, procured, activated, configured, and previously authorized the system. “Out of the loop” at the final instant therefore does not mean “outside the causal or responsibility chain.”

Rule-based logic Explicit conditions that allow, block, escalate, or terminate an action. Rules can be easier to audit than a statistical classifier, but they can still be incomplete, contradictory, misconfigured, or inappropriate when the environment changes.

Classification model An algorithm that assigns scores to predefined categories from available features. It does not discover the complete meaning of an object and cannot reliably express a category—such as lawful target or hostile intent—that is not adequately inferable from its inputs.

Prioritization system A mechanism that ranks tracks, alerts, or response options according to programmed objectives and constraints. A priority score reveals what the system was optimized to value, not what is inherently most important.

Authorization envelope The complete set of circumstances under which an action has been approved: objective, target or object class, location, time, evidence requirements, allowable effect, resource limits, abort rules, supervisory status, and applicable legal or operational constraints.

Abstention A designed output in which the system declines to classify, recommend, or act because evidence is insufficient, contradictory, unfamiliar, outside the approved envelope, or otherwise unsafe. Abstention is a capability, not simply a failure to produce an answer.

Assessment The post-action process of estimating the result, remaining threat, unintended effects, and need for further action. Assessment has its own uncertainty and must not equate loss of sensor contact with confirmed success.

The completed experience should leave visitors with neither a promise that automation makes war precise nor a claim that all automation removes human agency. Its final screen should show the live action compressed into two seconds and the prior human decisions extending backward across engineering reviews, testing, legal analysis, mission planning, configuration, and activation.

“When a machine acts in two seconds, was the human removed from the decision—or was the human decision made weeks before the event?”