When I was building an AI SOC for UAV AI Hackathon, our team decided to incorporate the principles of DoDD 3000.09 into our design. This directive addresses autonomy in weapon systems, stipulating that autonomous and semi-autonomous weapon systems shall be designed to allow commanders and operators to exercise appropriate levels of human judgment over the use of force. However, cyberspace operations are not covered under this directive. We nonetheless decided to incorporatate its principles into our solution, since our system’s actions directly affect real, physical UAV operations - with potential consequences ranging from strategic and tactical mission failures to lethal damage to both systems and personnel. Given this context, we implemented a requirement for human decision-making focused specifically on physical and lethal effects.
Table of contents
Open Table of contents
What Is DoDD 3000.09
DoDD 3000.09(Autonomy in Weapon Systems) is a US department of Defense policy on the development and use of autonomous and semi-autonomous weapon systems, issued in November 2012 and reissued in January 2023. Its core requirement fits in one sentence: “Autonomous and semi-autonomous weapon systems shall be designed to allow commanders and operators to exercise appropriate levels of human judgement over the use of force.”
But the directive explicitly excludes autonomous systems used for cyberspace operations. So applying it to a unmanned platforms and cyberspace operations isn’t a literal application.
Why We Implement It
Given that emergence of new technologies and methods for leveraging UAV’s across multiple use cases, the use of armed UAVs, including FPV drones, has extended to smaller units, such as battalions, companies, and even squads, as seen in Russia-Ukraine War. As a result, we decided to implement this directive’s core concept: Human-In-The-Loop(HITL)“
How It Was Reflected in Code - 4 Layers
The defense agent implements “appropriate levels of human judgment” as four layers of deterministic conrol.
| Layer | Role |
|---|---|
| Policy floor | A minimum baseline that always applies, regardless of model output |
| METT+TC escalation | Repurposes the Army’s mission-analysis framework as an escalation trigger-automatically elevates to human intervention once certain conditions are met |
| HITL enforcement | Physically irreversible commands, among others, require human approval at a deterministic gate that the AI cannot bypass |
| Guardrail | An output-limiting safeguard that operates out-of-model |
Policy Floor
- A static, hardcoded minimum that applies no matter what the model or any upstream heuristic recommends. Think of it as an unconditional backstop: even if every other layer would allow an action, the policy floor can still block it. This is what keeps a confident-but-wrong model output from becoming an excuted action.
METT+TC escalation
- A dynamic, situational layer that decides how much scrutiny an action needs, using the Army’s mission-analysis categories (Mission, Enemy, Terrain and weather, Troops and support available, Time available, Civil considerations) repurposed as escalating signals
- For example, how mission-critical is the current flight phase(Mission), how much time remains before the window to act closes(Time), how many other systems or missions would be affected(Civil considerations). If enough of these factors across a threshold, the system escalates handling from routine to mandatory human review-even for actions that the policy floor alone would have permitted.
HITL Enforcement
- The actual gate that acts on an escalation: it pauses execution and requires an explicit human “go” before the graph can proceed. This is the layer with teeth - the other three decide whether human judgment is needed; this one enforces that it actually happens
Guardrail
- The outermost restriction on the action space itself. This is where the model’s available tools/actions are scoped down before anything reaches a decision layer at all-comparable to the “Tool boundary” layer. If an action isn’t on the allowlist, the model can’t even attempt it, regardless of how the other three layers would judge it
How It Was Reflected in Code - 3 Mechanisms
HITL Interrupt
- When graph execution reaches a node flagged as high-risk (e.g., immediately before a physically irreversible command like takeoff), the state machine doesn’t just log a warning - it halts entirely, preserves its current state, and waits for an external signal before it will resume. Nothing downstream of that node executes until a human responds.
Single-use Token
- Once a human approves the paused action, the system issues a token that authorizes exactly one execution of exactly that action. The token can’t be replayed for a repeat of the same action and can’t be redirected to authorize a different one. This closes off two failure modes: a captured/leaked approval being reused later, and a single approval being stretched to cover more than what was actually approved
Out-of-band Verification
- The channel that grants approval is architectually seperate from the channel that executes actions. The AI agent process has no path to generate, intercept, or forge its own approval token; approval has to arrive through an independent route the agent doesn’t control. This is a standard seperation-of-duties pattern, applied here to keep the thing being supervised from also being able to supervise itself
HITL enforcement is implemented through three mechanisms: a HITL interrupt(execution auto-pauses requests approval on reaching a risk node), a single use token(cannot be reused, preventing replay attacks), and out-of-band verification(the approval channel is seperated from the execution channel, so the AI cannot forge its own approval)