Autonomous Weapons Policy on an Annual Clock: Design for Review, Not Assumptions
Back to Signal
AIDefenseAutonomyGovernmentCompliance

Autonomous Weapons Policy on an Annual Clock: Design for Review, Not Assumptions

September 8, 2026Jess Loban

What the memorandum actually directs

The White House's June 5, 2026 NSPM-11 directs the Secretary of War to update DoDD 3000.09 within 90 days and review it annually. Ninety days after June 5 is September 3. The instruction emphasizes the chain of command, operational authorities and consistency with the memorandum's policy.

That is a consequential requirement. It is not evidence that a revised directive was publicly issued by the deadline. The official directive text located for this review is dated January 25, 2023. A program should obtain the current authoritative version and implementation instructions before changing its approval assumptions. Annual review also does not necessarily mean annual amendment: a review may leave requirements unchanged.

Earlier versions matter when describing the history. The original directive dates to November 2012, and an official version incorporated a May 2017 change before the 2023 reissuance. Treating the entire interval as a decade without any revision obscures that record. The useful change now is an explicit recurring review obligation, with a predictable reason to revisit a program's policy baseline.

Human judgment is more precise than a slogan

The 2023 directive calls for appropriate human judgment over the use of force and establishes approval and testing responsibilities. Its treatment of autonomous systems is more detailed than a universal requirement that a person approve every individual action. It includes specified categories that do not require the particular senior review described in the directive, while remaining subject to other applicable approval processes.

An engineering team therefore needs to describe its actual function and intended use. Autonomous navigation, resupply, sensing, electronic effects and target engagement do not become interchangeable merely because they share software. Nor does labeling a system defensive or nonlethal automatically settle its legal and policy obligations. Counter-UAS systems are a good example of why mission, target, effect, supervision and operating environment must be considered together.

The memorandum alone does not establish a new lethal/nonlethal dividing line or a relaxed supervision threshold. Claims about such changes require the updated text. A supplier should bring a precise description of what the system selects, what it may engage, what the operator decides and how an operation ends. That gives policy and legal reviewers something concrete to assess.

Make the approved boundary visible in the design

For a program that takes years to develop, recurring review introduces a manageable engineering question: what evidence changes when the governing policy or intended mission changes?

Separate the relevant concerns in the architecture and documentation:

  • Mission behavior: what the system is intended to accomplish and in which environments.
  • Authority: which actions require approval, who may approve them and which permissions the system possesses.
  • Supervision and recovery: how operators understand state, intervene when required and place the system in an appropriate safe condition.
  • Evidence: which configuration, tests, limitations and assumptions support the approval.

These boundaries should be explicit even when components share a processor or software package. A clean interface makes an impact assessment easier; it does not make every policy change a simple parameter edit.

Configurable software still needs a new test campaign

Policy-configurable software can reduce the cost of implementing a change, especially when permissions and operational constraints are versioned rather than buried in an opaque integration. But accessible software is only part of the answer. A change may affect timing, sensing, operator workload, communications or physical safety, and can require hardware modifications and renewed review.

The 2023 directive specifically addresses modified systems whose algorithms, missions, environments, targets or expected countermeasures fall outside a prior approval. Teams should assess those conditions rather than assume an existing approval follows every software release. Verification and validation need to establish the behavior of the changed system, including interactions with the rest of the platform.

For example, changing when an operator must confirm an action can alter workload during a communications outage. Testing the authorization screen alone would miss the operational consequence. The change review must cover both the rule and the conditions in which people and equipment have to follow it.

A practical annual-review package

  1. Establish the baseline. Record the directive version, program approvals, intended use and unresolved interpretation questions.
  2. Map requirements to behavior. Link each relevant policy obligation to design controls, operating procedures and test evidence.
  3. Classify the change. Identify whether new software, targets, missions or environments remain within the approved scope. Seek the required review before treating the change as authorized.
  4. Plan regression and operational testing. Include operator understanding, intervention, degraded communications and interactions between autonomy functions.
  5. Preserve the decision record. Retain the approved configuration, limitations, release decision and training updates so the next review begins with evidence.

Industry has a constructive role in this cycle: provide credible capability data and make limitations visible. A review informed by reproducible tests is more useful than one driven by claims that a platform is generally autonomous or responsible. Programs that can explain exactly what changed, and what remained controlled, give decision-makers a stronger basis for timely approval.

Sources and further reading

Spartan X connects autonomy engineering, AI consulting and program execution at precisely this boundary: turning policy into testable behavior and maintaining the evidence needed to change a system responsibly.

Share this article
LinkedIn

BUILD WITH US

Ready to Solve Hard Problems?

Spartan X builds AI systems, autonomous platforms, and cybersecurity solutions for defense and national security.