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. This does not mean every navigation or resupply function is itself a weapon system covered by this directive. 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 an impact assessment
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
- Establish the baseline. Record the directive version, program approvals, intended use and unresolved interpretation questions.
- Map requirements to behavior. Link each relevant policy obligation to design controls, operating procedures and test evidence.
- 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.
- Plan regression and operational testing. Include operator understanding, intervention, degraded communications and interactions between autonomy functions.
- 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.
Separate the policy calendar from the release calendar
A recurring review can become wasteful if the program treats every anniversary as a reason to reopen every technical decision. It can become ineffective if teams wait for that anniversary to examine a consequential change. The better approach is to maintain the evidence continuously and use the formal review to resolve what has changed, what remains applicable, and what needs authoritative interpretation.
Three situations deserve different treatment. An unchanged policy and unchanged approved use may call for confirming the existing basis. A new interpretation may require clarifying documentation or procedures without changing the software. A changed mission or behavior may require substantial new analysis and testing. Program leadership should not assume those situations carry the same cost or timetable.
This distinction matters in supplier coordination. A contractor may be able to deliver a requested software change before the government has resolved whether the changed use is authorized. Delivery, technical acceptance, and permission to operate remain separate decisions. The schedule should show the dependencies among them so a completed engineering task is not mistaken for a completed approval process.
That is a governance and assurance issue, not advice about changing how a weapon engages. The responsible policy, legal, operational, and technical authorities must establish the actual boundaries for the specific system.
Fund the evidence that can survive a handoff
Program turnover can make even a well-supported decision difficult to reconstruct. A new reviewer should be able to determine which requirement was considered, which configuration was evaluated, what limitations were accepted, and who had authority to decide. A folder of test results without that relationship can leave the next team repeating work simply to understand the previous conclusion.
A focused evidence package may be more valuable than a larger document collection. Retain the relevant decisions and supporting records in a form the receiving team can use, with appropriate access and handling controls. Where an interpretation remains unresolved, identify it openly and state which activities depend on its resolution. Silence in a record should not be treated as approval.
The practical next step is to choose one pending program change and trace it through that package before committing its release date. If the supporting evidence transfers, explain why. If it does not, cost and schedule the additional work. This gives leaders a credible choice among proceeding within the existing approved scope, funding the reassessment, or deferring the change. It also keeps the annual policy cycle from becoming either an administrative ritual or a recurring surprise.
Sources and further reading
- NSPM-11 — update and annual-review direction
- DoDD 3000.09, January 2023 — policy, review and testing baseline located during research
- 2012 directive incorporating the 2017 change — revision history
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.
