The phrase "autonomous engagement" covers a wide range of actual system behaviors, and the ambiguity is operationally dangerous. A system that automatically slews a camera to a detected track and presents an engagement recommendation is "autonomous" in one sense. A system that detects, classifies, authorizes, and fires without human input is "autonomous" in a completely different sense — one with fundamentally different legal, ethical, and operational implications.
Building ARES-1, we've had to be precise about exactly where human authority sits in the engagement loop, what the system is permitted to do without human input, and how rules of engagement — which are ultimately a human policy artifact — get translated into system behavior. This post describes that architecture and the reasoning behind it. It's not a settled question in the broader defense community, and we're not claiming we've solved it definitively. But we have made concrete decisions, and we can explain them.
The DoD Directive 3000.09 Framework
DoD Directive 3000.09 (Autonomous Weapon Systems) establishes the foundational US policy framework for autonomous and semi-autonomous weapon systems. The directive distinguishes three categories:
- Autonomous weapon systems: Weapons that, once activated, can select and engage targets without further human operator input. The directive requires that these systems be designed to allow commanders and operators to exercise appropriate levels of human judgment over the use of force.
- Semi-autonomous weapon systems: Weapons that, once activated, are intended to only engage individual targets or specific target groups that have been selected by a human operator.
- Human-supervised autonomous weapon systems: A category introduced in the 2023 revision, covering systems where humans supervise operation and can intervene but where the machine selects targets within defined parameters.
The directive does not prohibit autonomous weapon systems. It requires that they be subject to appropriate human control and that they be designed to avoid unintended engagements. It also requires that they be built to comply with the laws of armed conflict, specifically International Humanitarian Law (IHL) requirements for distinction (distinguishing combatants from non-combatants), proportionality, and military necessity.
Where does ARES-1 fit? Our target operational mode is best described as human-supervised: the system operates within human-defined engagement parameters, executes engagements within those parameters autonomously, and presents status to a supervising operator who can intervene. The human operator does not make an individual engagement authorization decision for each threat — that's the point of the system. But the human operator defines the engagement envelope and can halt autonomous engagement at any time.
The Engagement Authorization Layer: Architecture
ARES-1's engagement authorization layer sits between the classification output (threat assessment) and the fire control system (engagement execution). It implements a set of operator-defined parameters that govern what the system is permitted to engage autonomously, and it presents a continuous status display to the supervising operator.
The authorization layer contains three classes of parameters, all operator-configurable before and during operation:
Threat qualification criteria: What constitutes a valid engagement target. Parameters include: minimum track quality threshold (classification confidence must exceed X%), minimum track duration before engagement is authorized (track must be at least N seconds old), required behavior flags (threat must have a converging track on the protected zone, not merely be proximate to it), and optional authorization whitelist (tracks that have been positively identified as authorized traffic are excluded from engagement regardless of other criteria).
Engagement envelope bounds: The physical space within which autonomous engagement is permitted. These are the range, altitude, and azimuth limits described in our engagement envelope post — they're not hardcoded defaults but operator-configurable parameters with sensible defaults and hard outer limits that cannot be exceeded.
Engagement inhibit conditions: Situations where autonomous engagement is suspended regardless of threat status. These include operator-commanded CEASE FIRE, low ammunition state below operator-defined threshold, sensor degraded state where classification confidence drops below minimum, and a configurable "engagement pause" that allows the operator to hold fire while investigating an ambiguous track.
The authorization layer runs continuously. When an active track meets all qualification criteria and falls within the engagement envelope and no inhibit conditions are present, it generates an "engagement ready" status for that track. The fire control system consumes that status and executes engagement. The operator sees the full decision chain in real time: which tracks are being evaluated, which criteria each track meets or fails, and which tracks are currently in "engagement ready" state.
Why We Did Not Build a "Confirm to Engage" Interface
The most common question we get about this architecture is: why doesn't the operator have to press a button to authorize each individual engagement? This seems like it would be more controllable — the human is in the loop for every shot.
The argument against per-shot human authorization for counter-UAS is primarily a throughput argument, but it's deeper than just speed. Against a coordinated swarm of 12 units arriving over a 30-second window, a "confirm to engage" interface requires the operator to make 12 individual engagement decisions in 30 seconds — one every 2.5 seconds. Under operational stress, with multiple simultaneous tracks on the display, each requiring individual confirmation, the human becomes the bottleneck and the saturation vector. The swarm is designed to defeat the human decision rate, not the machine's engagement rate.
More fundamentally, per-shot human authorization doesn't actually achieve the accountability it seems to promise. An operator confirming 12 engagement authorizations in 30 seconds under stress is not exercising meaningful judgment about each individual engagement — they're executing a rote confirmation action. The meaningful human judgment about engagement policy happens before and around the operation, not in the per-shot confirmation moment. The authorization layer we've designed puts the human judgment where it actually has content: in the threat qualification criteria, the engagement envelope, and the inhibit conditions that the operator has set and can adjust.
We're not saying per-shot confirmation is wrong for every system or every mission context. For a system with very long time-of-flight where there's genuine time for deliberation, or for a mission where the potential for misidentification is high and the consequences of a false positive are severe, per-shot human authorization may be the right design. For a fast-engagement counter-swarm system protecting a fixed installation, it undermines the core operational capability.
Rules of Engagement Translation: The Hard Problem
ROE in military operations are typically expressed in natural language: "Weapons free against all confirmed hostile UAS within the protected zone perimeter." Translating that into machine-executable parameters requires answering questions that the ROE text doesn't address.
What does "confirmed hostile" mean in machine terms? It means a track that has met the classification confidence threshold, the track quality threshold, the behavior criteria (converging track toward the protected zone), and has not been positively identified as authorized. This operationalization requires that each component of "confirmed hostile" be quantified — what is the specific classification confidence threshold? What is the specific track quality threshold? The ROE doesn't say.
What does "within the protected zone perimeter" mean for a kinetic intercept system? A threat is "within the perimeter" before it physically crosses it — at engagement range, the target is typically still outside the physical perimeter but on an approach trajectory that will breach it. The ROE concept of "within the perimeter" has to be translated into an intercept geometry that engages the threat before it reaches the perimeter, which requires defining an outer engagement boundary that is derived from the inner protected boundary plus the minimum engagement range plus track establishment time.
These translations are made when the operator configures the authorization layer parameters. They're not made by the machine autonomously. The operator who sets "classification confidence threshold = 78%" for a given deployment is making a judgment about what level of confidence is sufficient given the operational context — the value of the protected asset, the probability that authorized UAS are in the area, the consequences of a false positive. That judgment is irreducibly human. The machine enforces it consistently.
Logging, Accountability, and Post-Engagement Review
Every engagement event generates a complete log entry: track history, classification outputs at each evaluation cycle, authorization layer state at engagement commit, launcher state, round dispatch event, and (if available) post-engagement track observation. This log is tamper-resistant and time-stamped with GPS-synchronized time.
The purpose of this logging architecture is accountability and operational learning. If there is a question after an engagement about whether the system behaved correctly — whether it engaged a track that should have been excluded, or whether its classification was accurate — the log provides a reconstructable record of exactly what data the system had and what decisions it made. This is the machine equivalent of a voice-recorded engagement log in a manned system.
Post-engagement review of log data is part of the expected operational process. Operators should be reviewing engagement logs, not just counting engagement events. Patterns in the data — tracks that consistently reach "engagement ready" status but then leave the engagement zone before the round arrives, suggesting timing issues; tracks that trigger engagement but have borderline classification confidence — are the feedback that informs parameter adjustment in subsequent operations.
International Humanitarian Law and the Classification Problem
IHL compliance for autonomous weapon systems centers on the distinction requirement: the system must be capable of distinguishing between lawful targets and protected persons or objects. For a counter-UAS system, the relevant distinction is between threat UAS and civilian/authorized UAS — not between combatants and non-combatants in the traditional sense, but analogous to it.
Our classification architecture is designed around this requirement. The classification system does not engage any track that cannot be positively classified as a UAS with converging hostile behavior. A track that is "unclassified" — where the sensor data is ambiguous — does not generate an "engagement ready" flag. A track that is classified as a UAS but does not exhibit the behavior criteria (converging approach toward the protected zone at above-threshold velocity) does not generate an "engagement ready" flag.
This creates false-negative risk: a genuine threat that is misclassified or that exhibits an approach behavior that doesn't match the behavior criteria will not be engaged autonomously. That's an acceptable failure mode compared to false-positive engagement of authorized or civilian UAS. The authorization layer is designed to be conservative: when uncertain, it does not engage. The supervising operator can override that conservatism by expanding the engagement parameters if the tactical situation warrants, but the default behavior is to require positive evidence of threat behavior, not to act on negative evidence of non-threat behavior.
What This Architecture Does Not Solve
We've described an architecture that we believe is responsible and consistent with current DoD guidance for the specific application of counter-UAS fixed-site defense. But it's important to be clear about what this architecture does not resolve.
It does not answer the question of what the right autonomous engagement architecture looks like for offensive systems, for systems operating in civilian airspace, or for systems engaging threats that are not exclusively UAS. Those are harder problems with different legal and ethical dimensions.
It does not remove the possibility of engagement errors. No classification system achieves perfect accuracy. No engagement envelope definition perfectly captures the tactical situation in all possible scenarios. The architecture is designed to reduce the probability of erroneous engagements and to create accountability when they occur. It cannot eliminate them.
And it does not provide a stable answer to a policy question that is actively evolving. DoD Directive 3000.09 is under continuing review. International discussions about Lethal Autonomous Weapon Systems (LAWS) at the UN Convention on Certain Conventional Weapons (CCW) continue without resolution. The architecture we've built is compliant with current guidance; it will need to evolve as guidance does.
The human-defined ROE is not optional infrastructure we added for compliance optics. It's the foundation the entire engagement logic rests on. Remove the human-defined parameters and the system doesn't know what to do — not because the code fails, but because the question "what should be engaged?" is inherently a human question that machine systems can operationalize but cannot originate.