Build a joint capability from separate systems
Joint All-Domain Command and Control brings together data and decision-making across air, land, sea, space and cyberspace. The expanded term, Combined Joint All-Domain Command and Control, also reflects international partners. It is a concept guiding many investments, rather than a single network or acquisition program that can be installed everywhere at once.
The Army's Project Convergence, the Air Force's Advanced Battle Management System and the Navy's Project Overmatch are among the service efforts contributing to that work. They encounter different platforms and operational problems, but their interfaces ultimately need to support a force that combines crewed systems, autonomous vehicles and software decision aids.
Research update, September 2026: GAO's April 2025 review found progress in selected data-sharing efforts alongside weaknesses in the framework for guiding investments, measuring progress and sharing lessons. It also identified restrictive classification as a barrier. Those findings give program teams concrete institutional issues to address alongside technical interoperability; they are findings from that review, not a claim that every condition remains unchanged today.
Autonomy makes the integration question especially visible. A vehicle can produce a well-formed message that the receiving application cannot interpret correctly. A decision aid can display a recommendation without enough context for the person responsible for acting on it. Both systems may be connected and functioning as designed while the combined workflow remains inadequate.
Shared formats need shared meaning
Consider a surveillance platform reporting observations to an analyst and a separate automated application. The report may contain a timestamp, position, classification, confidence estimate and references to supporting observations. If the receiving systems interpret any of those fields differently, faster transport simply delivers the misunderstanding sooner.
An interface specification should therefore cover more than field names:
- Definitions and units: explain what each value means and how it was produced.
- Time and freshness: distinguish observation time, processing time and transmission time.
- Provenance: retain the source and relevant processing history.
- Uncertainty: identify what a confidence measure describes and the limits of comparing it across models.
- Revision handling: show when a report supersedes or corrects an earlier observation.
- Access rules: preserve classification, releasability and authorized uses across transfers.
Standardized APIs, common data models and documented versioning can make that exchange more dependable. The receiving team also needs representative test data, including incomplete and conflicting reports. A successful demonstration should show that a human analyst and an automated consumer can use the same underlying information without silently changing its meaning.
Traffic patterns belong in the test plan. Some platforms send steady telemetry; others transmit accumulated observations after a connection returns. Queues, delayed delivery and duplicate messages can affect the user experience and the reliability of downstream processing. Test the expected workload and credible degraded conditions rather than assuming every autonomous system generates the same data volume.
Confidence is evidence, not permission
A classification score does not establish identity, hostile intent, legal authority or permission to act. Its usefulness depends on calibration, the operating conditions and the underlying evidence. A system with a high numerical confidence can still be wrong, particularly when its inputs differ from those used in evaluation.
Authority needs its own representation. Programs should distinguish permission to collect information, distribute a report, recommend an action and execute an authorized function. The requirements for each are different. An alert that helps an operator investigate should not silently become approval for a consequential action elsewhere in the chain.
For systems within its scope, DoD Directive 3000.09 requires appropriate levels of human judgment over the use of force. That principle needs to be reflected in the complete workflow: user understanding, operating limits, relevant approvals and verification. A confidence threshold or a nominal human confirmation step cannot substitute for that work.
This is also a software assurance problem. The implemented permissions must match the approved operating concept. Teams need evidence that updates, malformed inputs or lost communications do not inadvertently expand those permissions.
Disconnection should narrow ambiguity
Degraded, disrupted, intermittent or limited communications change what a platform can know about the wider situation. They do not, by themselves, confer additional authority. Any permitted behavior during disconnection needs to be established in advance through the applicable operational and approval processes.
For architecture reviews, useful questions include:
- What information becomes stale when the connection is lost, and how is that shown?
- Which functions remain authorized, and which require renewed direction?
- How does the operator recognize the platform's actual communication and operating state?
- What record is retained locally, and how is it reconciled when connectivity returns?
- What evidence demonstrates predictable behavior when services fail or inputs conflict?
These questions apply to many nonlethal functions as well: navigation support, equipment monitoring, logistics and information collection. Resolving them early reduces the temptation to invent an operational workaround after deployment.
Make integration evidence a shared deliverable
Platform developers and command-and-control teams should agree on interfaces, operating boundaries and acceptance evidence while both designs can still change. Waiting until a vehicle is complete can leave the receiving organization dependent on proprietary adapters, manual reformatting and undocumented assumptions.
A practical joint review should include operators, data owners, security staff and the people responsible for approving the intended use. Demonstrate one complete workflow, record the limitations and repeat it after a meaningful software or interface change. Share the results across participating programs so that each team does not rediscover the same problems.
The goal is a mixed force whose systems can exchange useful information and remain accountable within their assigned roles. That requires sustained ownership of the interfaces and the evidence, long after the first connection succeeds.
Sources and further reading
- GAO: Defense Command and Control—Further Progress Hinges on Establishing a Comprehensive Framework, April 2025
- DoD Directive 3000.09: Autonomy in Weapon Systems
Spartan X's engineering, AI and cybersecurity practices connect these responsibilities: interoperable data, clearly bounded automation and evidence that supports the operator's actual mission.
