A brigade staff receives a report that a supply route may be impassable. An AI-assisted planning application proposes an alternative. The recommendation appears in the common operational picture, where a separate movement application can turn it into a revised convoy schedule. The first tool was supposed to advise. The second can change an operational plan. Who authorized the transition between them?
This is a hypothetical command-post scenario, not an account of a defect in the Army’s Next Generation Command and Control (NGC2) system. Its point is that three different things can happen in sequence: information arrives, software interprets it, and another application takes an action. All three steps can work exactly as designed while a critical question remains unanswered. Was the receiving application actually empowered to turn that information into the particular action it took? In a dispersed formation, such a handoff could alter when a unit expects fuel or ammunition, or which route a support element prepares to use. That would make the boundary a command problem, not merely a software bug.
The distinction matters now. In October 2026, the Army announced initial application contract awards for I Corps, moving NGC2 beyond division-level prototyping toward a larger ecosystem of commercial, government, and soldier-developed software. These tools are intended to work across command and control, intelligence, movement and maneuver, sustainment, protection, and fires. The Army is rightly seeking faster decisions and fewer disconnected systems. But interoperability should never allow one application to borrow an authority that belongs to another, or to a human commander.
The New Seam in Command and Control
The Army’s June 2026 common data layer baseline established a foundation for applications to exchange and use operational information. The Army’s own NGC2 developer portal now describes modular, frequently updated software that can come from commercial suppliers, government developers, or soldiers. This architecture creates an opportunity to replace slow, isolated information flows with a shared software ecosystem.
It also changes where errors can arise. An application might produce a trustworthy assessment but have no right to direct another system. A message might have a valid digital signature while referring to an outdated approval. A queued request might arrive twice after communications return. An upgraded workflow might recognize a new data field without recognizing the limits that accompanied the original decision. These are possible integration failures to test, not findings about deployed NGC2 components.
Traditional interoperability reviews ask whether data can be exchanged, parsed, displayed, and used. That is necessary. The more consequential question arises when one application uses another’s output to change an authoritative record or initiate an operational action: alter a movement schedule, publish an authoritative logistics status, release a task for execution, or modify a mission-support configuration. The data interface and the authority interface are not the same interface, even when the software hides the difference.
Army doctrine recognizes that command is fundamentally an exercise of human authority and judgment. The July 2026 edition of ADP 6-0, Command and Control continues to describe mission command as the Army’s approach to empowering subordinate decisions and decentralized execution. Software can support that approach; it cannot inherit a soldier’s professional judgment merely by processing the same information. Commanders may authorize bounded actions in advance, including when communications are degraded. The technical system must distinguish those permissions from a general license to act.
Test the Handoff, Not Just the App
NGC2 provides a practical occasion to treat the boundary between applications as an object of testing. Rather than asking only whether each tool behaves correctly in isolation, evaluators should trace a proposed action across the complete chain: the source report, the recommendation, the approval, the receiving application, and the resulting operational change.
A workable test begins with a simple record of permission: which application or user may initiate which class of action; which human or organizational authority approved it; which software and policy versions apply; how long the permission lasts; and what to do when the required evidence is missing. This need not become another sprawling enterprise registry. For an integration event, it can be a versioned, machine-readable test fixture against which each handoff is judged. The requirement is modest: Data should not carry executable authority by implication.
Five controlled drills would reveal more than a demonstration in which every link stays up and every application receives an ideal input.
First, make the advisory boundary visible. Feed a mission-support tool a recommendation that exceeds its permission to act. The receiving workflow should display it as advice or require the defined approval step before making a consequential operational change. A green model-confidence indicator must not be treated as an authorization credential.
Second, change one software version while holding the rest of the workflow constant. Repeat an otherwise legitimate request with a policy or configuration identifier that is no longer approved. Evaluators should see whether the destination checks the applicable permission, rather than accepting the request simply because its signature and format are valid. Rapid software delivery makes this a recurring release test, not a once-per-program event.
Third, interrupt a permitted mission-support workflow and restore communications. Some previously authorized local actions may properly continue within defined limits; others may need fresh authorization. The test should distinguish an old event being synchronized into the record from a new action being authorized for execution. No node can know of a revocation that never reached it. That limitation requires preapproved operating bounds and a reconciliation procedure, not magical assumptions about real-time awareness.
Fourth, duplicate or withhold evidence. Retransmit a queued request, omit a required approval record, or present an internally consistent but incomplete history. A sound integration test should not mistake repeated delivery for a new order, or a neat audit trail for proof that every prerequisite occurred. Where completeness cannot be established, evaluators should record the uncertainty rather than quietly mark the case as passed.
Fifth, inject disagreement between checking paths. If one component reports that permission is valid and another detects an expired or mismatched rule, the inconsistency should reach the designated decision-maker instead of disappearing behind whichever screen happens to look green. Agreement between two programs is not conclusive if both rely on the same mistaken source; that limitation should remain visible in the report.
These are proposed unclassified test cases. They can start with synthetic workflows and simulated disruptions, but that only demonstrates whether the test design is coherent. Testing real NGC2 performance would require authorized access to actual interfaces, operators, configurations, and government evaluation facilities. No such operational validation is claimed here.
Give Commanders a Release Decision They Can Use
The Army is not starting from zero. The Army Test and Evaluation Command’s continuous NGC2 evaluation effort combines development feedback, laboratory risk reduction, and operational assessment. At Project Convergence–Capstone 6, soldiers and evaluators exercised NGC2 under demanding conditions. The proposal is therefore not to invent a new test bureaucracy or assert that the Army Test and Evaluation Command has ignored authorization. It is to make cross-application permission a separately visible release question within the evaluation work already under way.
For each software update or new integration, the program office and operational stakeholders could require a short permission-handoff record: the affected action classes; the approved roles and policy versions; the adverse cases tested; the number of legitimate actions incorrectly blocked; the time and burden required to resolve conflicts; and any cases in which the evidence did not support a confident decision. The responsible authority would set risk-appropriate thresholds before reviewing the results. There is no single threshold suitable for every function from logistics reporting to more consequential mission actions.
This matters because bad controls can defeat the purpose of modernization. A rule that rejects every disconnected action may protect a narrow test condition while preventing an authorized unit from sustaining itself. A rule that accepts every cached permission may preserve apparent speed while allowing software to exceed its mandate. The relevant measure is not how often a checker says “no.” It is whether legitimate work continues within declared bounds while unauthorized transitions are surfaced before they become operational effects.
A commander should not have to interpret software test logs to understand that trade-off. The useful output is a decision sheet that distinguishes four cases: demonstrated conformance, demonstrated violation, insufficient evidence, and conflicting verification. Engineers can implement the checks; evaluators can challenge their results; program managers can decide whether a release meets acceptance criteria. Commanders still own mission decisions and the risk they accept. A technical pass is not an operational order.
Do Not Confuse Speed with Permission
The Army’s modernization pace gives this question urgency. In late October, the Army again emphasized the role of open, extensible NGC2 applications and continuing soldier-led experimentation as it prepares to scale its architecture. The practical advantage of modular software is that useful capabilities need not wait for the next generation of hardware. The corresponding obligation is to check what each update is newly able to do, and whose authority it now relies upon.
The battlefield will not offer perfect connectivity, perfectly synchronized software versions, or unlimited time for a commander to inspect every automated handoff. The Army should therefore rehearse the handoff before the next operational update reaches a unit: a report becomes a recommendation; a recommendation reaches an executable application; and the application must show that the right authority followed it across the seam.
NGC2 will be judged by how well it helps formations understand the fight and act before an opponent can. That speed is worth pursuing. But a common data layer is not a common permission to act. The Army should test the difference before the software turns a recommendation into an action the commander never authorized.
Burak Oktenli is an independent researcher whose work focuses on machine authority, software assurance, and national security. He holds a BS in computer science and engineering from the University of South Florida and an MBA from Lynn University. He is completing a master of professional studies in applied intelligence at Georgetown University.
The views expressed are those of the author and do not reflect the official position of the United States Military Academy, Department of the Army, or Department of Defense.
Image credit: Spc. Jonathan Reyes, US Army
