.svg){kind=icon}
Learn
CJADC2 architecture is the federated, data-centric design for Combined Joint All-Domain Command and Control that connects many existing systems into one decision-ready picture through a common data layer, standards, and interfaces rather than a single central repository, so joint and coalition forces reason over the same data.
Last updated: October 18, 2026
Why it matters to your mission. A commander whose picture is assembled by hand from a dozen disconnected systems is deciding late, on partial data, in a fight that moves faster than the reconciliation. CJADC2 architecture is the data design that connects those existing systems into one decision-ready picture through a shared data layer instead of one more central database. The outcome is a joint and coalition force that reasons over the same data, fast enough to decide first, with every shared element traceable back to its source.
CJADC2 architecture is the federated, data-centric design for Combined Joint All-Domain Command and Control that connects many existing systems into one decision-ready picture through a common data layer, standards, and interfaces rather than a single central repository, so joint and coalition forces reason over the same data. It is sometimes called the CJADC2 reference architecture, the data fabric, or the common data layer. The architecture is defined less by any one application than by how data moves, is described, and is governed across the systems that were never built to work together.
The design choice at its center is federation. The United States is not going to pour every sensor feed, intelligence report, and logistics record into one database and run the war from it. The systems of record already exist, owned by different services and partners, at different classifications. CJADC2 architecture is the layer that lets them behave as one network without being collapsed into one store.
Key takeaways
CJADC2 architecture is the set of data, interface, and governance decisions that let many separate command-and-control and intelligence systems operate as one decision network. It is the plumbing beneath the vision, and it is a data problem before it is a sensor or application problem. The sensors mostly already exist. What is missing is the layer that makes their output comparable, combinable, and shareable fast enough to matter.
Independent oversight describes the chosen approach directly. The U.S. Government Accountability Office, in Defense Command and Control: Further Progress Hinges on Establishing a Comprehensive Framework (GAO-25-106454, 2025), reports that the Chief Digital and Artificial Intelligence Office is pursuing "a computing environment that effectively connects existing federated data across multiple systems and mission areas" rather than a single centralized repository. That one sentence is the architecture in miniature: connect what exists, in place, through a shared layer.
For an architect, CJADC2 is not a box to install. It is a set of requirements that many systems have to meet in common, so the integration and governance layer, not any one sensor or application, is where the effort succeeds or stalls.
It is a data architecture, not a single system. There is no CJADC2 appliance a program office can buy and field. CJADC2 is a goal state reached by making many existing and future systems interoperate through shared data standards and interfaces. The architecture, not a product, is the unit of work.
GAO's central finding shows the risk this creates. Without a comprehensive framework to guide investments and measure progress, the services "continue to pursue their command and control projects largely in isolation," building capabilities that do not align. A data architecture only delivers one picture if the systems feeding it agree on how data is described and exchanged. Absent that common framework, each program builds its own connections, and the promised single picture fragments back into the many it was meant to replace.
So the architecture question is a governance question. The design is federated by necessity; whether federation produces coherence or chaos depends on common standards enforced across programs, not on any single system's cleverness.
The common data layer is the shared middle of the architecture: the standards, services, and governance that let data from many systems be described, found, combined, and shared consistently, without first being copied into one database. It is what people mean by a data fabric or data mesh in this context. The authoritative data stays in its system of record; the common layer is how every other system can make sense of it.
A workable common data layer has to do several jobs at once:
Treat the common data layer as plumbing and it stays invisible until it fails. Treat it as the load-bearing part of the architecture, which it is, and the rest of CJADC2 has something solid to stand on.
Because a single central repository is neither buildable nor desirable here. The data already lives in authoritative systems owned by different services, agencies, and partners, at different classifications and under different releasability rules. Pulling all of it into one store would mean a years-long migration, a single point of failure, and a collision with the classification and foreign-disclosure rules that keep data compartmented on purpose.
Federation inverts that. Instead of moving the data to one place, the architecture reasons across it where it lives, through the common data layer. GAO describes exactly this: connecting "existing federated data across multiple systems and mission areas" rather than centralizing it. The authoritative sources stay intact, owned by whoever owns them, and the architecture adds a layer of understanding on top.
The table contrasts the two approaches at the level that decides an architecture.
| Dimension | Single central repository | Federated common data layer (CJADC2) |
|---|---|---|
| Where data lives | Copied into one central store | Stays in its authoritative system of record |
| Integration method | Migrate and consolidate | Connect and reason across data in place |
| Ownership | Concentrated in the central system and its vendor | Each system and partner retains ownership of its data |
| Classification and releasability | One pooled store strains compartmentation | Enforced per record as data moves across boundaries |
| Failure mode | Single point of failure; migration risk | Degrades gracefully; no one store to lose |
| Vendor dependence | High; the central platform defines the model | Lower, if interfaces are open and the layer is government-owned |
| Fit to coalition sharing | Poor; pooling collides with foreign disclosure | Native; releasability enforced at the data layer |
The federated choice is not a compromise. It is the only design that respects how defense data is actually owned and classified while still producing one picture to reason over.
This is the part the "Combined" makes hardest, and the architecture has to answer it at the data layer rather than after the fact. In a combined force, a shared track or report has to carry who may see it, and that marking has to be enforced as the data moves across a national or classification boundary, not checked once and forgotten.
Oversight has flagged this as a central obstacle, not an edge case. GAO found that data tagged "Not Releasable to Foreign Nationals" is unavailable to any non-U.S. entity, and that overly restrictive classification policies significantly impede the information sharing a combined force depends on. An architecture that treats releasability as a policy problem bolted on later will leak, over-restrict, or both. One that treats it as a property of the data, enforced in motion, can share what partners are allowed to see and withhold what they are not, by design.
That is why provenance and releasability are not features layered on top of CJADC2 architecture. They are part of the common data layer itself, because a combined force cannot act on a picture it cannot govern or trace.
AI fits where the volume of federated data outruns human attention: correlating sensor reporting, resolving which records across feeds describe the same real-world object, and surfacing the few things a commander needs from a coalition-wide picture. In a federated design, that correlation is the work. Without it, one physical contact shows up as three unlinked records and the single picture never forms.
The constraint is that the architecture cannot act on an answer it cannot trace or govern. A combined force cannot stake a decision on a fused track that no one can explain, or that silently crossed a releasability line. So AI in CJADC2 has to be decision support that keeps provenance and releasability intact: the model makes sense of the picture faster, and the governance decides what a partner may see and leaves a trail back to the source. Speed without that governance is how a federated network decides on fiction or leaks what it should have held.
Torch.AI builds government-owned reasoning infrastructure that connects to data where it already lives, which is exactly the federated layer CJADC2 architecture turns on. Rather than replacing systems of record or centralizing them, the reasoning layer complements them: it connects fragmented, multi-source data, preserves meaning across systems, makes relationships explicit, and routes outputs into mission workflows, so a joint or combined force can reason over one coherent picture at machine speed.
Where the public products fit in the common data layer: NEXUS makes multi-source data meaningful, turning fragmented records from many systems into a semantic representation the mission can reason over. HALO makes the relationships understandable, resolving which records describe the same object and fusing them into a graph an analyst can trust and trace. For maritime and Navy or joint deployments, that capability is delivered as ORCUS. Because the infrastructure can be deployed government-owned, the customer keeps control of the integration and releasability logic rather than renting it inside a vendor's proprietary environment, which is directly responsive to the vendor lock-in and proprietary-interface concerns GAO raised. Ownership varies by deployment and purchase (government-owned or commercial); the point is that the government-owned model is available when the mission needs it. You can see how this is packaged as a capability on the Torch.AI software page.
This is the systems of record versus system of reason distinction at the center of Torch.AI's approach: the existing systems keep recording the authoritative data in place, and the reasoning layer on top turns that federated data into a shared, governable picture a coalition can act on.
Scoping a CJADC2 data layer or a federated integration effort? Bring these requirements to a technical walkthrough and we will run them against your environment and a sample of your multi-source data: request a technical walkthrough.
It is the federated, data-centric design that connects many existing command-and-control and intelligence systems into one decision-ready picture through a common data layer, standards, and interfaces, rather than a single central repository. GAO describes the government approach as connecting existing federated data across multiple systems rather than centralizing it.
A data architecture, not a single system. There is no CJADC2 appliance to buy; it is a goal state reached by making many existing and future systems interoperate through shared standards and interfaces, which is why GAO found the services building capabilities in isolation without a comprehensive framework to align them.
The shared standards, services, and governance that let data from many systems be described, found, combined, and shared consistently without first being copied into one database. It is what is meant by a CJADC2 data fabric or data mesh, and it has to preserve provenance and enforce releasability as data moves.
Because the authoritative data already lives in systems owned by different services, agencies, and partners at different classifications. Centralizing all of it would mean a years-long migration, a single point of failure, and a collision with foreign-disclosure rules. Federation reasons across the data where it lives instead.
Releasability has to be a property of the data, enforced as it moves. GAO found that data tagged 'Not Releasable to Foreign Nationals' is unavailable to any non-U.S. entity and that restrictive classification policies significantly impede combined information sharing, so the architecture must enforce who may see each record at the data layer.
AI correlates sensor data and resolves records that describe the same object across federated feeds, surfacing what a commander needs faster than people can by hand. It has to keep provenance and releasability intact, because a combined force cannot act on a fused track it cannot trace or govern.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
