How Defense Primes Are Responding to the JADC2 Architecture

The Pentagon’s Joint All-Domain Command and Control initiative — JADC2 — is not a program. It is a strategy, a mandate, and increasingly, an architectural forcing function. For defense systems engineers, that distinction matters. There is no JADC2 contract to win. There is, instead, a growing expectation that every major defense system — airborne sensor, ground vehicle, naval platform, space asset — must be designed to participate in a shared data fabric that enables decision superiority across all domains simultaneously.

The systems engineering implications of that expectation are substantial, and the industry response has been uneven. Some primes are ahead. Some are generating documents that look like compliance without producing the architectural connective tissue that JADC2 actually demands. This article examines where the execution is real, where it is performative, and what the hardest engineering problems actually are.

What JADC2 Actually Requires

The Pentagon’s 2022 JADC2 Implementation Plan established five functional priorities: assured command and control, enterprise network and infrastructure, data and applications, AI and autonomy integration, and workforce development. For systems engineers, the first four translate into concrete technical obligations.

Assured command and control means resilient, degraded-mode-capable connectivity. Architecturally, this pushes toward mesh networking, prioritized data flows, and graceful degradation specifications — all of which must live in interface control documents and system requirements before they can be built.

Enterprise network and infrastructure means the transport layer must support DoD-wide interoperability. In practice, this is where legacy system integration becomes painful. AN/TYQ-23 tactical operations centers, legacy Link 16 terminals, and platform-specific radio stacks were not designed with a common data fabric in mind. Bridging them requires interface adaptation layers, and those adapters require specifications someone has to own and maintain.

Data and applications means JADC2-aligned programs are expected to adopt common data standards — primarily the DoD Data Strategy’s emphasis on FAIR data principles (Findable, Accessible, Interoperable, Reusable), and specific standards like NIEM, NATO STANAG messaging formats, and increasingly, the Open Mission Systems / Universal Command and Control Interface (OMS/UCI) standard. Writing requirements that enforce data standard compliance across a system-of-systems is a different activity than writing subsystem performance requirements. Most traditional requirements management processes were not designed for it.

AI and autonomy integration means that JADC2-compliant systems must be able to expose data to AI-enabled decision aids and accept tasking from autonomous orchestration layers. This is where the requirements challenge becomes particularly sharp: how do you specify a behavioral contract for an AI-driven interface when the interface behavior is partially learned rather than fully deterministic?

Where Requirements Break Down

JADC2 compliance at the platform level is relatively tractable. Define the required interfaces, specify the data formats, write the latency and throughput requirements, verify in test. That is hard engineering work, but it is within the scope of what defense systems engineers know how to do.

The problem is that JADC2 is a system-of-systems problem, and system-of-systems requirements have a structural defect: no one fully owns them.

In a single-contractor program, the prime is responsible for requirements decomposition. Interface control documents flow down from a system-level architecture, and the prime enforces them. In a multi-contractor JADC2-aligned program — a common pattern when connecting an Air Force sensor network to an Army ground vehicle to a Navy surface combatant — interface specifications exist in a contested space between program offices, prime contractors, and integration authorities.

The current DoD approach attempts to solve this through Architecture Integration Teams and through designated System of Systems Integration Technical Authorities. The Connecting Combat to JADC2 initiative within the Army’s PEO C3T has made some of the clearest progress here, establishing a formal Interface Control Working Group structure for Project Convergence experiments. But working group structures produce coordination mechanisms, not authoritative specifications. When contractor A’s interface implementation diverges from contractor B’s expectation, who resolves the delta? In most current programs, that answer is still “slowly and expensively.”

The Program Offices Furthest Ahead

ABMS (Advanced Battle Management System): The Air Force’s contribution to JADC2 remains the most ambitious and the most scrutinized. After an Acquisition Strategy reset in 2022 and ongoing debates about modular open system architecture implementation, ABMS has made genuine progress in defining a government-owned data layer — the Command and Control Extensible Architecture (C2E) — that is intended to decouple application logic from transport infrastructure. The architecture is sound in concept. The requirements challenge is that C2E-compliance obligations for individual program-of-record systems are still being defined in a piecemeal fashion through individual program acquisition strategies rather than a unified requirements authority.

Project Convergence: The Army’s experimentation campaign has been the most operationally grounded JADC2 activity in the DoD. PC-22 and PC-23 demonstrated real cross-domain kill chain compression, and the requirements artifacts generated from those experiments — particularly the interface specifications between TITAN, IBCS, and Joint FIRES integration — represent some of the most concrete JADC2 requirements documentation currently in existence. The Army’s challenge is converting experiment-derived specifications into program-of-record requirements before vendor implementations diverge.

Project Overmatch: The Navy’s undersea and surface integration effort has taken a different approach, emphasizing data standards compliance over architectural mandates. The Program Executive Office for Command, Control, Communications, Computers, and Intelligence (PEO C4I) has published detailed data model requirements for JADC2 node participation that are more immediately actionable than ABMS’s architectural framework. The tradeoff is that data-standards-first approaches can produce interoperability at the data layer while leaving command and control logic fragmented.

CJADC2 Joint Technical Synchronization Office (JTSO): Established to coordinate across service implementations, the JTSO has published a JADC2 Reference Architecture but has limited authority to enforce compliance. The reference architecture is a useful alignment document. It is not a requirements baseline.

Legacy System Integration: The Unavoidable Problem

Approximately sixty percent of the C2 infrastructure the DoD operates today will still be in service in 2035 by most analytic estimates. Legacy tactical data links, aging ground station software stacks, and platform-specific communications architectures are not going away because JADC2 arrived.

The pragmatic response from most primes has been gateway architecture: build adaptation layers that translate legacy system outputs into JADC2-compliant data formats. Northrop Grumman’s work on IBCS integration adapters, Raytheon’s Link 16 to OMS/UCI translation work, and L3Harris’s legacy radio modernization line all follow this pattern.

Gateway architectures work. They also create a new class of systems engineering problem: the gateway itself has requirements, interfaces, and failure modes that must be specified, traced, and tested. In many current programs, gateways are treated as integration middleware rather than system components with first-class requirements. That is an error. When the gateway fails or produces latency violations, the kill chain breaks — and if there are no formal requirements against the gateway, there is no contractual basis for resolving the failure.

Writing gateway requirements correctly means treating every legacy interface adapter as an ICD-owning component with performance specifications, fault tolerance requirements, and data integrity obligations. Few current programs have done this comprehensively.

How Interoperability Requirements Are Being Written — And Where the Process Falls Short

The traditional approach to interoperability requirements in defense programs relies on Interface Control Documents (ICDs), Interface Requirements Specifications (IRSs), and System of Systems Interface Design Descriptions (IDDs). These documents work within a single program’s configuration management baseline. They struggle to maintain coherence across program boundaries.

The deeper problem is that JADC2 interoperability requirements are fundamentally graph-structured. A given system node doesn’t just have an interface to one other system — it participates in a network of relationships with data flowing in multiple directions, with conditional behaviors depending on network topology and degraded-mode states. A document-centric requirements approach represents this poorly. A flat ICD between system A and system B doesn’t capture what happens when system C is unavailable and A must reroute through D with reduced bandwidth.

This is pushing some advanced programs toward graph-based systems modeling approaches. MBSE adoption in JADC2-aligned programs has accelerated meaningfully in the last two years — not because MBSE is new, but because the architectural complexity of JADC2 makes document-centric requirements management visibly insufficient. SysML-based models in tools like Cameo and MagicDraw are increasingly being used as the primary requirements artifact for interface specifications, with documents generated from the model rather than maintained separately.

The practical limitation is that model-based approaches require significant toolchain investment and trained practitioners. For smaller subcontractors and second-tier suppliers entering JADC2 supply chains, MBSE adoption is inconsistent. The interoperability gap often lives at that boundary — between a prime’s sophisticated systems model and a supplier who is still managing interfaces in a spreadsheet.

Tools that can lower the barrier to structured, traceable requirements management across contractor boundaries are beginning to see interest in JADC2-adjacent programs. Flow Engineering, which structures requirements around knowledge graphs and uses AI to surface traceability gaps and interface conflicts, is one example of a newer generation of tooling being evaluated by teams that need to move faster than traditional requirements document workflows allow — particularly when managing interface changes across multi-contractor boundaries where the cost of a missed link is high and the document review cycle is long.

What a JADC2-Aligned Acquisition Actually Looks Like

The programs making the most concrete progress share a set of structural characteristics worth naming.

First, they have a designated interface authority with actual configuration management control over the shared data schema. Not an advisory body. Not a coordination mechanism. An authority that can reject non-compliant interface implementations and require rework.

Second, they treat interoperability requirements as first-class contractual artifacts with acceptance criteria that can be verified in integration test. “Shall be JADC2 compliant” is not a requirement. “Shall publish target track data in OMS/UCI message format at a minimum update rate of 2 Hz with latency not to exceed 150ms end-to-end under degraded link conditions” is a requirement.

Third, they maintain traceability from the JADC2 Reference Architecture down to system-level requirements and interface specifications. When the reference architecture updates — and it will — the impact on downstream requirements is visible without manual analysis.

Fourth, they have an explicit plan for legacy system integration that treats gateway components as first-class systems with their own requirements, not as integration conveniences that will be handled during development.

Honest Assessment

JADC2 is a genuine architectural transformation with real strategic value. It is also the most complex system-of-systems integration challenge the DoD has attempted. The systems engineering community’s response has been uneven: sophisticated at the prime level, inconsistent at the supplier level, and structurally limited by requirements processes that were designed for single-program contexts.

The programs furthest ahead — Project Convergence, PEO C4I’s data standards work — have succeeded by being specific: specific about interface formats, specific about interface ownership, specific about acceptance criteria. The programs generating the most noise without the most progress have substituted architectural vision documents for requirements baselines.

For defense systems engineers working in JADC2-adjacent programs, the operational guidance is straightforward: demand an interface authority, write interfaces as requirements not descriptions, trace everything to the reference architecture, and treat every legacy adapter as a system component. JADC2 won’t be won at the architecture level. It will be won or lost in the ICDs.