Why Legacy Defense Procurement Struggles to Build Kill Webs

Why Legacy Defense Procurement Struggles to Build Kill Webs

Executive summary

The Department of Defense’s central acquisition problem is no longer simply how to buy a better aircraft, ship, sensor, or missile. It is how to buy and continuously evolve a mission system whose operational value emerges from interactions among many independently managed platforms, networks, data services, applications, and weapons. A “kill web,” as used in this report, is a dynamically composable sensor-to-decision-to-effect architecture in which data and targeting functions can move across service, platform, classification, and coalition boundaries. This is an analytical definition rather than a single statutory DoD definition; many relevant technical and operational details remain classified or program-specific.

The legacy acquisition system is optimized around a bounded product: a platform with a designated requirements sponsor, program executive office, acquisition category, prime contractor, test program, budget line, configuration baseline, and sustainment organization. A kill web is almost the inverse. It is a continuously changing system of systems whose most valuable attributes—interoperability, data availability, adaptability, resilience, and speed of software insertion—cannot be owned or delivered by any one platform program. DoD’s own JADC2 strategy acknowledges that existing service acquisition processes routinely produce domain-specific capabilities that cannot, by themselves, satisfy all-domain command-and-control needs. GAO subsequently found that DoD still lacked a comprehensive framework for identifying CJADC2 capabilities, investments, responsibilities, and progress. citeturn6view5turn10view1turn19view2

The problem is not principally that the FAR or Title 10 prohibit agile, modular acquisition. The government already has a software acquisition pathway under 10 U.S.C. § 3603, middle-tier pathways under § 3602, prototype other-transaction authority under § 4022, commercial-solutions-opening authority under § 3458, modular-open-systems requirements under §§ 4401–4403, modular contracting under FAR Part 39, and flexible IDIQ ordering under FAR Subpart 16.5. The deeper problem is that these mechanisms sit inside a larger requirements, budgeting, test, cybersecurity, sustainment, and organizational system that remains predominantly program- and platform-centric. citeturn14search1turn14search3turn3search1turn14search2turn2search0turn2search4turn2search19turn14search0

The principal findings are:

The unit of accountability is misaligned with the unit of military value. Program managers are held responsible for cost, schedule, performance, and readiness of their assigned platform—not for the end-to-end performance of a cross-service mission thread. A platform program therefore has strong incentives to protect its baseline, certification status, schedule, and proprietary technical architecture even when opening the system would improve joint operational performance. GAO has repeatedly found that DoD policies outside the dedicated software pathway do not fully incorporate iterative development, continuous user feedback, and portfolio-level termination or redirection of weak efforts. citeturn15search1turn19view1turn16search6

The budget system funds components more readily than connective tissue. Platform production, modernization, and sustainment have established program elements and constituencies. Cross-program interfaces, common data models, shared test environments, identity services, gateways, and integration software are often distributed across research, procurement, and operations appropriations and across multiple service sponsors. The software and digital-technology budget activity pilot was created precisely because selected software programs otherwise had to manage development, procurement, and sustainment through multiple appropriation categories. citeturn3search7turn6view2

Contract structures often price stable deliverables better than continuous adaptation. Firm-fixed-price contracts work best when specifications, quantities, interfaces, and acceptance criteria are sufficiently definite. They transfer substantial cost risk to the contractor, but in uncertain software integration this can encourage conservative assumptions, narrow statements of work, change-order behavior, or risk premiums. Cost-type contracts accommodate uncertainty but can reward effort rather than mission outcomes. IDIQs, commercial solutions openings, and OTAs can improve speed and competition, yet none solves the downstream problems of production transition, common architecture, certification, appropriations, or incumbent-controlled interfaces. citeturn2search3turn2search11turn14search16turn14search12turn3search1turn14search2

Intellectual-property and data-rights decisions made early can determine competition and adaptability decades later. DFARS policy permits DoD to tailor the software, technical-data deliverables, and license rights it needs, but those needs must be identified, priced, and placed on contract. The F-35 demonstrates the consequences of postponing that work: GAO reported in 2026 that limited access to technical data continued to hinder government maintenance, competitive sustainment, and readiness initiatives, and that several related recommendations remained open. citeturn2search22turn2search2turn2search6turn19view3turn18search3

Cybersecurity and test processes remain organized around individual system boundaries. Risk Management Framework authorization, platform safety certification, weapon integration testing, and operational test are necessary, but they can make every new interface or software release a bespoke recertification event. Continuous authorization offers a better model, but DoD guidance requires mature automated monitoring, active cyber defense, and a secure software supply chain; it is not merely a waiver from security controls. citeturn5search2turn7view3

Industry responds rationally to the government’s revenue signals. Traditional programs provide relatively predictable revenue through development, production lots, engineering changes, integration work, upgrades, and sustainment. A genuinely modular kill web requires vendors to disclose interfaces, tolerate third-party components, make replacement easier, and compete repeatedly for software increments. Without alternative compensation—portfolio-scale demand, platform-stewardship fees, integration incentives, recurring competitions, and predictable transition funding—open architectures can conflict with the incumbent’s economic interest in protecting future integration and sustainment revenue. This is an economic inference from prevailing contract structures, data-rights disputes, and sustainment experience, rather than an allegation of improper contractor conduct. citeturn2search3turn2search22turn19view3turn15search13

The recommended solution is not to abandon platform programs. Aircraft, ships, missiles, and safety-critical embedded systems still require disciplined systems engineering and configuration control. DoD should instead separate the relatively stable physical and safety-critical layers from rapidly evolving mission applications, data services, and interfaces, then manage the latter as enduring cross-platform portfolios. Congress’s establishment of portfolio acquisition executives in the FY2026 NDAA and DoD’s stated intention to move from platform-centric structures toward integrated capability suites are directionally aligned with this need. Implementation, however, is too recent to judge, and GAO notes that many prior iterative-acquisition recommendations remain unimplemented. citeturn16search1turn16search5turn19view0turn19view1turn15search18

The structural mismatch

A standalone platform can be decomposed into a work breakdown structure and assigned to a single accountable acquisition organization. A kill web is better understood as an ecosystem and operating model:

flowchart LR
    S1[Air, space, maritime, land and cyber sensors]
    S2[Allied and intelligence sources]
    A[Adapters, gateways and message translation]
    F[Data fabric, metadata, discovery and common schemas]
    C[Command-and-control applications and decision aids]
    E[Weapons, electronic effects and maneuver forces]
    R[Battle-damage, status and learning feedback]

    S1 --> A
    S2 --> A
    A --> F
    F --> C
    C --> E
    E --> R
    R --> F

    Z[Identity, zero trust, cross-domain security and continuous monitoring] --- A
    Z --- F
    Z --- C

    G[Portfolio governance: standards, interfaces, data rights, test and funding] --- A
    G --- F
    G --- C
    G --- E

The architecture has no single natural program boundary. Its performance depends on semantic data compatibility, network quality, identity and access management, timing, classification release rules, software quality, platform adapters, weapon interfaces, and human command relationships. DoD’s JADC2 strategy accordingly emphasizes sensing, making sense, and acting; enterprise-scale data standards; resilient networks; layered security; and faster, unified processes. citeturn7view4turn17search4

A platform-centric acquisition system tends to treat the interfaces as subordinate elements of the platform. A kill-web model must treat interfaces, data, and mission threads as first-class products. The difference is summarized below.

The key distinction is not “hardware versus software.” Modern aircraft and ships are already software-intensive. It is closed product optimization versus open mission-system optimization. A platform can have millions of lines of software and still be acquired as a closed, vertically integrated product. Conversely, a kill web can contain highly controlled, safety-critical modules while exposing stable, governable interfaces to a wider ecosystem.

A useful acquisition decomposition is therefore:

1. Physical and safety-critical platform layer: propulsion, flight controls, ship control, weapon safety, structural and environmental functions.
2. Platform mission-system layer: sensors, electronic warfare, onboard computing, tactical displays and weapon-management functions.
3. Connectivity and data layer: radios, gateways, identity, routing, data fabrics, schemas and cross-domain services.
4. Mission-application layer: command-and-control workflows, targeting services, decision aids, AI models and user interfaces.
5. Portfolio integration layer: reference architecture, conformance testing, shared digital engineering, cyber evidence and mission-thread evaluation.

The layers should not all have the same release cadence or certification process. The procurement failure occurs when a change in the mission-application or data layer must be negotiated, funded, integrated, tested, and certified as a unique modification to every participating platform.

Acquisition and programmatic mechanics

Statutes and regulations provide flexibility, but accountability remains program-centric. The software acquisition pathway under 10 U.S.C. § 3603 and DoDI 5000.87 is intended to support iterative development, active user involvement, frequent delivery, and ongoing measurement of value. Middle-tier acquisition under § 3602 supports rapid prototyping and rapid fielding. Section 4022 permits prototype OTAs and, under specified conditions, follow-on production; § 3458 authorizes commercial solutions openings. Sections 4401–4403 direct use of modular open systems approaches in major systems to the maximum extent practicable and establish responsibilities for major-system interfaces. citeturn14search1turn3search0turn14search3turn3search1turn14search2turn2search0turn2search4

These authorities address pieces of the problem but do not automatically create an integrated portfolio. A platform may use the software pathway for an application while its radio, cloud environment, weapon interface, intelligence feed, and partner system remain under different pathways, appropriations, program offices, and release schedules. GAO found that the dedicated software pathway most fully reflected iterative development, while policies for urgent, middle-tier, and major-capability pathways did not consistently incorporate the complete iterative cycle for cyber-physical products. citeturn15search1turn15search22

Requirements create durable organizational boundaries. Traditional requirements processes are effective when a sponsor can define a needed platform capability and assign responsibility to a program. Kill webs require requirements at several levels simultaneously: platform performance, interface behavior, data semantics, network resilience, human workflow, coalition releasability, and end-to-end mission outcome. When these are decomposed into service-specific requirements documents, the joint mission thread can become a collection of “coordination requirements” without a budget-owning authority capable of enforcing tradeoffs.

For example, one service may optimize sensor fidelity, another weapon range, and another network survivability. Each choice may be reasonable locally, but the combined system may suffer excessive latency, incompatible security labels, insufficient bandwidth, or ambiguous track-quality metadata. GAO found that services were developing distinct CJADC2-related capabilities and that DoD had not established a comprehensive framework for determining what counted as CJADC2, how investments related, or how progress should be assessed. citeturn10view1turn19view2

Milestone incentives favor baseline protection. A platform program is evaluated against an approved baseline and scheduled decisions. Cross-platform integration introduces dependencies the program manager cannot control: another service’s software release, a coalition accreditation decision, a satellite-communications upgrade, or a new common data model. The rational response is to minimize external dependencies, defer interfaces, or implement proprietary workarounds that the program can control. The result is predictable platform delivery at the expense of adaptable joint integration.

The legacy logic can be represented as follows:

flowchart TB
    R[Service-sponsored platform requirement]
    B[Dedicated budget line and acquisition baseline]
    P[Prime-led design and supplier structure]
    T[Platform-specific test, cyber authorization and certification]
    F[Fielded configuration]
    S[Long-term platform sustainment contract]

    R --> B --> P --> T --> F --> S

    K[Cross-service kill-web need]
    K -. coordination request .-> R
    K -. interface dependency .-> P
    K -. joint test dependency .-> T
    K -. upgrade request .-> S

    X[No single owner of end-to-end mission performance]
    K --> X

The diagram does not imply that platform accountability is undesirable. It shows why adding a joint coordination body above unchanged program structures rarely suffices. The coordinating organization can identify dependencies but may lack authority to change requirements, redirect money, compel interface delivery, or accept risk across the participating programs.

PPBE timing and appropriations fragment software products. A software-defined network has persistent needs: development, cloud hosting, licenses, cyber operations, user support, model updates, hardware refresh, test infrastructure and integration. These activities can fall into RDT&E, procurement, operation and maintenance, or working-capital structures depending on their purpose and maturity. The resulting handoffs can break product teams and encourage artificial declarations that software has moved from “development” to “sustainment,” even though modern software continuously performs both functions. DoD’s software and digital-technology budget activity pilot allows selected efforts to combine development, acquisition and sustainment within a single RDT&E budget activity, reflecting recognition of this mismatch. citeturn3search7

The broader PPBE process also rewards mature, legible program claims over uncertain portfolio integration. A destroyer, fighter lot, or radar upgrade can be described in units and production quantities. A shared data fabric, API modernization effort, or joint test environment is harder to attribute to a single service output and easier to reduce during budget drills. DoD’s PPBE reform implementation material has acknowledged outdated or unclear guidance, administrative delays, and the need to improve understanding of industry economics and market timelines. citeturn6view2turn7view2

Contract type is often confused with acquisition strategy. FAR firm-fixed-price contracting assigns the contractor maximum cost risk and full responsibility for resulting profit or loss. This can be effective for stable hardware, well-understood software modules, or repeatable services. For exploratory integration, however, bidders must either price uncertainty, limit contractual scope, or depend on later modifications. The problem is not fixed price itself; it is using fixed-price logic before interfaces, user needs, dependencies, and acceptance tests are sufficiently understood. citeturn2search3

Cost-reimbursement arrangements can support uncertain development and integration, but they need short increments, transparent technical evidence, government product ownership, and credible off-ramps. Otherwise, expenditure and labor can become proxies for progress. FAR’s cost-plus-fixed-fee rules cap fee and leave the contractor with limited direct financial exposure to overruns, making technical governance and incremental acceptance especially important. citeturn2search11

Multiple-award IDIQs are well suited to recurring needs whose exact timing and quantity are uncertain, and the FAR generally establishes a preference for multiple awards and fair opportunity at the order level. They can support a kill-web ecosystem if task orders are modular, interfaces are common, and vendors can compete on comparable outcomes. An IDIQ becomes much less transformative when the scope is tied to one incumbent architecture, when only one vendor can access the integration environment, or when task orders continually extend a monolithic code base. citeturn14search0turn14search12turn14search16

OTAs and commercial solutions openings can reduce procurement-cycle friction and attract nontraditional firms. They are particularly useful for experiments, competitive demonstrations, prototypes and initial software increments. Their limitations arise after the prototype: an operational program still needs appropriated funding, cybersecurity authorization, test evidence, data rights, sustainment, integration with existing platforms and an empowered transition owner. GAO’s work on rapid pathways shows that labeling an effort “rapid” does not overcome immature technology, weak oversight, or incomplete iterative practices. citeturn3search1turn14search2turn15search22turn16search6

Prime-subcontractor structures centralize integration but can impede ecosystem competition. A traditional prime contractor can coordinate thousands of subsystems, maintain configuration control and accept responsibility for platform performance. Those are valuable functions. The tension arises when the same firm controls system integration, proprietary interfaces, test tools, technical baselines and sustainment. Third-party insertion then becomes a modification to the prime’s product rather than a normal market transaction.

The government typically has contractual privity with the prime, while subcontractor data-rights assertions, proprietary components, supplier warranties and integration constraints flow upward through the prime’s architecture. Replacing a subcomponent may therefore require negotiations across several contractual layers. DoD should not eliminate prime integrators; it should distinguish platform integration, for which a prime may be accountable, from portfolio architecture and interface governance, which the government must be able to direct.

Technical, governance and lifecycle barriers

Data rights are an architectural control mechanism. DFARS clauses distinguish among technical data and computer software and provide different license-rights categories based partly on development funding and the nature of the material. DoD policy is not to buy every possible right indiscriminately, but to acquire the software, documentation, deliverables and license rights necessary for the government’s identified lifecycle needs. Acquisition plans for major systems are supposed to address these needs, and deliverables should be specified and separately identified where practicable. citeturn2search2turn2search6turn2search22turn2search21

For kill webs, the minimum strategically important package often includes:

• interface-control documentation and machine-readable API definitions;
• data schemas, metadata rules and information-assurance attributes;
• source code or sufficient software rights for government-maintained adapters when operationally necessary;
• build instructions, dependency manifests and software bills of materials;
• test harnesses, simulated data, digital models and conformance suites;
• rights to modify or recompete integration work;
• configuration and vulnerability information needed for continuous authorization.

A blanket demand for unlimited rights would be counterproductive. It could raise prices, deter commercial vendors, and appropriate privately funded technology unnecessarily. The appropriate policy is segmented rights: protect vendors’ reusable algorithms and background IP while ensuring that government-funded interfaces, mission-specific integration layers, test artifacts and operational data can be used to sustain competition and mission continuity.

The F-35 illustrates the cost of deferred decisions. GAO reported that technical-data limitations prevented or delayed government maintenance projects, complicated organic repair, and could threaten a new sustainment-improvement strategy. As of 2026, several data-related recommendations remained open, and DoD’s planned transfer of sustainment responsibilities continued to depend on resolving technical-data needs and timelines. citeturn19view3turn18search0turn18search3

Cybersecurity is both a real operational requirement and a transaction cost. A kill web increases the number of trust relationships, software dependencies, interfaces and potential attack paths. It therefore cannot be secured by relaxing controls. The problem is that traditional authorization processes often assess a relatively static system boundary, whereas a software ecosystem requires continuous evidence about code, infrastructure, identities, dependencies and operational telemetry.

DoD’s continuous-authorization approach requires an existing authorization foundation, ongoing monitoring, active cyber defense and a secure software supply chain. It also recognizes that different platforms and environments may retain separate authorization boundaries. The policy opportunity is to standardize and reciprocally accept evidence—not to presume that authorization for one platform automatically covers all connected systems. citeturn7view3turn5search2turn5search26

A workable model would authorize a common software factory, deployment pipeline and runtime environment, then assess application-specific deltas through automated controls. Platform safety authorities would continue to control flight-, ship- and weapon-critical functions. Mission applications operating outside those safety kernels could update more rapidly, provided interface constraints, rollback procedures, telemetry and isolation are demonstrably enforced.

CMMC and DFARS cybersecurity requirements are also important for protecting controlled unclassified information across the supplier base. Yet compliance costs can be proportionately heavier for small and nontraditional firms, which are often the desired sources of software, AI and communications innovation. GAO has documented small-business concerns about CMMC implementation. DoD therefore needs shared secure development environments, subsidized onboarding, clear data segmentation and contract structures that do not require every small software supplier to reproduce the infrastructure of a major prime. citeturn5search3turn5search7turn5search11turn12search3

Interoperability standards require governance, not merely publication. DoD instructions establish policies for interoperability, supportability and IT standards. The JADC2 strategy similarly calls for common and evolvable data standards. Yet a standard can exist while implementations remain incompatible because of optional fields, divergent profiles, proprietary extensions, timing behavior, security markings, version drift or different interpretations of semantics. citeturn5search1turn5search9turn7view4

Effective governance requires:

• an authoritative owner for each interface and data model;
• versioning and backward-compatibility rules;
• automated conformance tests available to all authorized vendors;
• reference implementations and representative synthetic data;
• a waiver process with expiration dates and remediation plans;
• operational mission-thread tests, not only message-format compliance;
• coalition release profiles designed from inception rather than added after U.S.-only development.

GAO found that CJADC2 experiments lacked a common lexicon and guidance in some areas, that lessons were not always disseminated across the department, and that classification, intelligence-community access and coalition standards created delays or limited data sharing. These are governance problems as much as technical problems. citeturn10view3turn10view2

Lifecycle sustainment remains organized around platforms and vendors. Traditional sustainment plans focus on depots, spares, technical publications, reliability, supply support and periodic modifications. A kill web also requires an enduring product organization for software, data and integration. Its work does not end at initial operational capability. It must preserve API compatibility, patch vulnerabilities, update data models, maintain test infrastructure, refactor code, manage cloud and network costs, and adapt applications as adversary behavior changes.

A common failure mode is to fund a software prototype and then transfer it to a sustainment organization without the engineering team, development pipeline, automated tests or rights required to evolve it. Another is to treat every software update as a new platform modification. The result is “frozen agility”: a system designed through agile methods but sustained through infrequent, contract-heavy baseline changes.

Supply-chain constraints affect kill webs at both hardware and software layers. Distributed command-and-control depends on radios, processors, displays, antennas, cryptographic equipment, satellite capacity, cloud infrastructure and rugged edge computing. These components can have long lead times, sole or foreign sources, export restrictions and platform-specific qualification requirements. GAO has identified gaps in DoD’s visibility into foreign dependencies; in the F-35 supply chain, prohibited Chinese-origin magnets contributed to manufacturing interruptions while alternatives were identified. citeturn12search4turn18search21

Software supply chains add open-source packages, commercial libraries, container images, development tools, model weights and cloud services. Resilience therefore requires both industrial-capacity measures and technical measures: multiple qualified suppliers where practical, component inventories, software bills of materials, reproducible builds, dependency monitoring, escrow or continuity arrangements, and architectural substitutes for scarce components. DoD’s industrial strategy emphasizes resilient supply chains, workforce capacity and flexible acquisition, but those goals must be translated into specific portfolio contracts and architecture decisions. citeturn12search2turn12search9turn12search18

Culture reinforces the formal barriers. Government program managers are often rewarded for avoiding breaches, protests, cyber incidents and test failures. They are less directly rewarded for exposing their platform to a difficult joint integration event that could reveal problems outside their control. Contracting officers may favor familiar clauses and vendors because novel structures create personal and schedule risk. Requirements communities may view evolving requirements as indiscipline. Test organizations may receive integrated systems late, after design choices are costly to reverse.

Traditional primes face parallel pressures. Business units are generally organized around programs and customer accounts. An open interface that benefits a joint portfolio may impose cost or schedule risk on a platform contract without providing revenue or profit to that business unit. Subcontractors can be reluctant to expose privately funded designs. Software teams may be measured by delivery dates while cyber, safety and operational-test organizations are measured by the avoidance of failures. The cumulative outcome is not caused by one irrational actor; it is a rational equilibrium produced by misaligned incentives.

Case studies

F-35: software-intensive but still vertically integrated. The F-35 demonstrates that a platform can be highly networked and software-dependent while remaining difficult to evolve as a modular ecosystem. Block 4 modernization and Technology Refresh 3 combine new processors, memory, cockpit hardware, mission software, weapons integration, test aircraft, laboratories and supplier capacity. In 2025, GAO reported that Block 4 was more than $6 billion above earlier estimates and at least five years later than originally planned; combat-capable TR-3 delivery was expected in 2026 after hardware and software delays. citeturn18search1turn18search4turn18search6

DOT&E reported that TR-3 hardware and software problems led to stored aircraft and acceptance of aircraft with truncated software that disabled some previously fielded combat functions. As of the end of September 2025, 158 TR-3-configured aircraft had been delivered to U.S. services, but no combat-capable TR-3 aircraft had yet been delivered. DOT&E also identified limited operational-test aircraft, multiple configurations, funding and contracting delays, and inadequate software stability as obstacles to representative testing. citeturn19view4turn20view3

The lesson is not that the F-35 should have been acquired as a loose collection of apps. Flight safety, low-observable performance, sensor fusion and weapon employment require rigorous integration. The lesson is that hardware refresh, platform mission software, weapons certification, test capacity and sustainment data became tightly coupled. When one layer slipped, aircraft delivery and downstream capability integration slipped with it.

The sustainment experience adds the business and IP dimension. GAO reported in 2026 that limited technical-data access continued to inhibit repairs and sustainment improvement, while industry capacity constraints threatened delivery of some critical parts even where additional funding was planned. citeturn18search28turn19view3

For future kill-web participants, DoD should use the F-35 as a warning against assuming that possession of an advanced platform guarantees control of its upgrade ecosystem. Interface rights, test infrastructure, digital models, software pipelines and repair data must be designed into the acquisition strategy.

Aegis and destroyers: a partial counterexample with continuing physical constraints. Aegis shows the benefits of common software and open architecture. The Navy’s Aegis Common Source Library supports reuse and commonality across multiple configurations. Baseline 9 introduced more modular functions and network-oriented, open-architecture computing, while capabilities such as Naval Integrated Fire Control–Counter Air connect distributed sensors and shooters. citeturn8search1turn8search5turn8search9turn8search12

This is closer to a kill-web model than a wholly platform-unique combat system. Common source software can reduce divergent code bases, permit capability reuse and facilitate integration across ship classes. Aegis also retains a strong government and warfare-center technical ecosystem, which can provide more architectural continuity than an entirely contractor-owned product.

The limits remain significant. Aegis baselines must integrate with specific radars, launchers, ship computing plants, networks and combat-system configurations. GAO found, for example, that Constellation-class frigate integration depended on Aegis software updates, SPY-6 integration and testing that could not be completed fully until the lead ship was at sea. citeturn8search10

The operational lesson is that common software does not eliminate platform integration. It changes the problem from writing a wholly unique system for every hull to managing a disciplined family of configurations. The procurement lesson is to fund and govern the common source, interface standards, laboratories and integration infrastructure as enduring products rather than charging every improvement to an individual ship installation.

CJADC2, ABMS, Project Overmatch and Project Convergence: experimentation without complete portfolio authority. CJADC2 is the most direct institutional effort to build a kill web. The Air Force’s ABMS, the Navy’s Project Overmatch and the Army’s Project Convergence provide service-specific contributions, while the Chief Digital and Artificial Intelligence Office’s Global Information Dominance Experiments provide recurring joint experimentation. DoD announced an initial CJADC2 capability in 2024, and GIDE operated on roughly 90-day cycles to test and field data-sharing and decision-support capabilities. citeturn17search10turn17search22turn17search9turn17search2

GAO’s 2025 assessment nevertheless found that DoD had struggled to define the full CJADC2 portfolio, track investments and establish a comprehensive management framework. Services continued to develop unique capabilities, and lessons from experiments were not consistently shared. Classification, intelligence-system access, coalition data release and inconsistent standards imposed additional delays. citeturn10view1turn10view3turn19view2

The experiments also show what is possible when authority, users and software teams are closely connected. GAO reported that the XVIII Airborne Corps’ Scarlet Dragon-related efforts produced 62 software updates over ten months and reported a roughly 600 percent efficiency improvement in a targeting workflow. That figure was reported by the organization and should not be interpreted as a department-wide, independently validated performance result, but the release cadence demonstrates the value of persistent operational experimentation. citeturn10view2

The central limitation is transition and scaling. An experiment can connect selected systems through temporary gateways, special network permissions, contractor support and senior-leader attention. A fielded kill web must repeat that performance across hundreds of units, routine funding cycles, multiple classification domains, contested communications, allied environments and changing software versions. The acquisition system is reasonably capable of creating demonstrations; it is less capable of turning their common services and interfaces into enforceable portfolio infrastructure.

The emerging portfolio model is promising but unproven. The FY2026 NDAA established portfolio acquisition executives with authority over capability portfolios and required iterative development authority, including the ability to modify, discontinue or terminate efforts. DoD’s 2025 Acquisition Transformation Strategy explicitly called for moving from program- and platform-centric structures toward integrated suites of capabilities across platforms and segments of kill chains. citeturn16search1turn16search5turn19view0turn19view1

This is the most important structural reform in the current policy landscape because it can align mission value, budgets and accountability. Its effectiveness will depend on whether portfolio executives receive genuine control over requirements, funding, architecture, test priorities and program tradeoffs. A portfolio office that can review programs but cannot redirect money, enforce interfaces or change release schedules would reproduce the existing coordination problem under a new title. As of mid-2026, GAO considered it too early to observe tangible results from the latest reforms. citeturn15search18turn16search6

Reform package and industry model

The reforms should be treated as an integrated package. Faster contracting without architecture control can produce more incompatible systems. Open standards without data rights can produce nominal compliance but continued vendor dependence. Portfolio governance without flexible funding can produce responsibility without authority.

Industry revenue and incentive changes

Industry will support open, modular systems consistently only when the business model makes openness economically sustainable.

Compensate architecture stewardship explicitly. A firm asked to maintain an open platform or common service should receive predictable revenue for interface management, backward compatibility, vulnerability response, developer support and conformance tooling. DoD should not expect a prime to surrender future proprietary integration revenue in exchange for an unfunded obligation to support competitors.

Pay for third-party integration success. Award-fee, incentive-fee or task-order evaluation criteria should include the time and cost required to integrate a qualified third-party module, the percentage of interfaces passing automated conformance tests, release reliability, vulnerability-remediation time and successful operation across multiple platforms. A prime’s profit should increase when the ecosystem becomes easier—not harder—to extend.

Create recurring, credible competitions at modular boundaries. Competition “for the platform” once every decade is not enough. Mission applications, adapters, analytics and selected infrastructure services should face periodic competitions using shared test data and operational scenarios. Incumbents should retain an advantage only to the extent that their product performs better, not because competitors cannot access interfaces or test environments.

Use portfolio-scale demand signals. Small and nontraditional firms often face a gap between a successful prototype and a program-of-record order. DoD should publish conditional demand curves: for example, successful conformance and operational performance can trigger orders across a defined number of units or platforms. This makes the government’s potential market legible to private investors and suppliers. Acquisition literature on industry engagement identifies differences in government and commercial time horizons, access barriers and uncertain transition pathways as obstacles to broader participation. citeturn15search13

Preserve commercial reuse. Vendors should generally retain rights to privately funded tools, reusable algorithms and commercial products. DoD should seek rights to government-funded integration code, mission-specific data products and operationally essential interfaces. A balanced approach expands the supplier base; a blanket government-ownership policy could cause leading commercial firms to decline participation.

Use consumption models selectively. Cloud, compute and some software services may be bought through subscriptions or consumption pricing, but contracts need ceilings, usage visibility, data portability, exit assistance and alternative deployment paths. Otherwise, variable pricing can obscure lifecycle cost and replace platform lock-in with cloud or data-platform lock-in.

Reward lifecycle affordability and substitutability. Source selections should evaluate the expected cost and time to replace a component, export data, change a model, support disconnected operations and transition to another integrator. These attributes have economic value even when they do not improve initial demonstration performance.

Provide long-term signals for constrained physical supply chains. Radios, processors, cryptographic devices and rugged edge hardware may need multiyear commitments, economic-order quantities, supplier qualification funding and strategic inventories. Software modularity cannot compensate for unavailable hardware. Conversely, long-term hardware commitments should require open or government-governed software interfaces so that supply assurance does not create a permanent closed stack.

Retain independent technical capacity inside government. A modular ecosystem transfers more architecture and integration responsibility to DoD. The government must therefore employ product managers, software architects, data engineers, cyber specialists, contracting officers and test personnel capable of evaluating vendor claims and maintaining the reference architecture. Outsourcing all technical authority to a lead integrator would recreate the dependency the modular model is intended to reduce. RAND’s work on digital engineering similarly identifies standardization, tool interoperability, workforce shortages, legacy integration and cultural change as central implementation challenges. citeturn15search2turn15search6

Prioritized action agenda

The priorities below assume no fixed budget ceiling, as requested. They are ordered by institutional leverage and dependency rather than estimated cost.

The most important first move is to establish one accountable owner for each selected mission thread with control over architecture, money and integration priorities. Standards, OTAs, software factories and experiments will remain fragmented tools until such an owner can compel programs to deliver the interfaces, evidence and release schedules the joint mission requires.

The second move is to make the government’s technical architecture real in contractual terms. A diagram labeled “open architecture” has little effect unless contracts specify deliverable interfaces, license rights, reference implementations, test assets, version rules and remedies for nonconformance.

The third move is to change the economic proposition for industry. DoD cannot simultaneously demand open interfaces, rapid third-party insertion, lower switching costs and continuous competition while paying incumbents mainly for proprietary integration labor and long-term sole-source sustainment. Open ecosystem stewardship must become a funded deliverable and a source of profit.

The fourth move is to preserve rigor while changing cadence. Safety certification, operational test, cybersecurity and configuration control are not legacy obstacles to be removed; they are essential functions that must be redesigned around automated evidence, reusable authorization, digital engineering, layered architectures and continuous mission-thread evaluation.

The final strategic objective should be a defense acquisition system in which a new sensor, algorithm, command application or weapon can join a mission network through known interfaces, predictable rights, reusable security evidence, representative test environments and recurring competitive opportunities. That would not eliminate platform programs. It would make them participants in a government-governed combat ecosystem rather than isolated products connected through expensive, one-off integration projects.