The Architecture of Friction: Why Legacy Defense Procurement Struggles to Build Kill Webs

The Architecture of Friction: Why Legacy Defense Procurement Struggles to Build Kill Webs

The Strategic Transition from Kill Chains to Kill Webs

The fundamental calculus of military advantage is undergoing a structural transformation. For decades, the United States Department of Defense (DoD) and allied militaries have organized tactical operations around the concept of the "kill chain"—a linear, sequential framework utilized to find, fix, track, target, engage, and assess an adversary1. The legacy kill chain is inherently brittle because it operates as a static sequence with predefined data exchanges between specific platforms1. In this construct, the entire operation moves only as fast as its slowest node, and the disruption of a single link—whether through electronic jamming, kinetic destruction, or software failure—can halt the entire process1. In highly contested environments characterized by advanced anti-access/area-denial (A2/AD) threats, adversaries explicitly target these linear links, turning structural brittleness into an unacceptable operational risk1. In response to these vulnerabilities, defense strategy has pivoted toward the concept of the "kill web." The kill web replaces the two-dimensional static sequence of the kill chain with a multidimensional, dynamic mesh network that spans all six domains of warfare: space, air, land, surface, subsurface, and cyber/electromagnetic3. Rather than relying on a singular pathway, a kill web distributes critical functions across a vast array of sensor, decision, and strike nodes. If one node drops out or a communications pathway is degraded, the network dynamically routes around the failure, seamlessly integrating another node capable of fulfilling the same function1. This architecture transforms the battlespace into a decentralized marketplace of sensors and effectors, maximizing the lethality of disaggregated forces by matching the optimal sensor with the best-positioned weapon, regardless of the military branch that owns them4. This conceptual shift is deeply intertwined with the doctrine of "Mosaic Warfare," which advocates decomposing large, multi-mission platforms into smaller, specialized nodes that can be rapidly recombined in highly adaptable formations5. The urgency of this transition has been heavily reinforced by contemporary conflicts, notably the Russo-Ukrainian War. Observations from Ukraine demonstrate the emergence of adaptive kill webs utilizing edge computing, decentralized command, and the rapid integration of distributed uncrewed systems5. By employing software-enabled kill webs and artificial intelligence (AI) to compress the Observe-Orient-Decide-Act (OODA) loop, forces have demonstrated the ability to sustain information flow and operational tempo even in heavily degraded, bandwidth-constrained environments5. AI tools, such as the Maven Smart System and advanced Geospatial AI (GeoAI), are now capable of simultaneously processing massive volumes of drone footage, synthetic aperture radar (SAR), telemetry, and open-source intelligence to instantly correlate pattern-of-life data and generate automated targeting recommendations7. However, realizing this vision across the broader U.S. military requires a fundamental overhaul of how technology is acquired, funded, and sustained. The legacy defense procurement system was meticulously engineered during the Cold War to acquire monolithic hardware platforms—such as aircraft carriers, stealth bombers, and main battle tanks—over multi-decade development cycles9. This industrial-era acquisition apparatus is now structurally misaligned with the demands of software-defined, network-centric warfare11. The competitive advantage of a modern combat system is no longer judged solely by its isolated kinematic performance, but by its ability to seamlessly share and enrich data across the entire kill web11. Attempting to build an agile, continuously updated software network using a procurement system designed for static hardware platforms has resulted in profound institutional friction.

The Platform-Centric Procurement Trap

The core structural barrier to establishing effective kill webs is the persistent platform-centric bias inherent in the defense acquisition apparatus. The DoD organizes its procurement around Program Executive Offices (PEOs), which are structurally incentivized to manage discrete portfolios of ships, aircraft, or ground vehicles12. These program offices operate in relative isolation, developing proprietary systems and bespoke architectures optimized strictly for the specific requirements of their individual platforms3. This "stovepiped" approach results in the acquisition of highly capable but digitally isolated weapon systems that cannot natively communicate with assets outside their immediate ecosystem3. Historically, when the DoD has attempted to solve this by mandating universal network architectures, the efforts have largely failed due to overly ambitious, top-down requirements. Programs such as the Joint Tactical Radio System (JTRS), the Transformational Satellite Communications (TSAT) system, and the Army’s Future Combat Systems (FCS) collapsed because they attempted to "leap ahead" and skip an entire generation of technology9. For example, the JTRS program mandated that all military radios comply with the Software Communications Architecture (SCA). However, the policy was implemented prematurely, and the compliance guidelines were not technically mature enough to support the high data rates and frequencies required for wideband communications, leading to massive instability across acquisition programs9. Furthermore, the bureaucratic offices tasked with overseeing these net-centric transformations—such as the Office of the Assistant Secretary of Defense for Networks and Information Integration (ASD/NII)—were given oversight responsibilities but denied the actual budget authority to enforce their mandates across the fiercely independent military services9.

The Datalink Dilemma: A Case Study in Hardware Isolation

The consequences of this platform-centric procurement model and the ensuing lack of centralized enforcement are most acutely demonstrated by the interoperability challenges surrounding the United States Air Force’s premier fifth-generation fighter aircraft: the F-22 Raptor and the F-35 Lightning II. Despite both being stealthy, highly advanced platforms designed to dominate the airspace, they were developed sequentially with proprietary, incompatible communication architectures14. When the F-22 was developed, its designers equipped it with the Intra-Flight Data Link (IFDL) to allow secure communication among other F-22s. IFDL is a highly directional system designed to have a low probability of intercept and low probability of detection (LPI/LPD), enabling the fighters to share tactical data without compromising their radar-evading stealth profiles14. A decade later, the F-35 was fielded with the Multifunction Advanced Data Link (MADL), a Ku-band system that also utilizes fast-switching, narrow directional beams to coordinate F-35 strike forces17. Because these two datalinks rely on distinct, hardware-baked waveforms and proprietary message formats, the F-22 and F-35 cannot natively exchange high-fidelity sensor data in flight without compromising their stealth15.

While both platforms possess the capability to receive data via the older, omnidirectional Link 16 standard used widely across NATO, utilizing it presents severe tactical disadvantages. The F-22 cannot natively transmit its highly advanced "God's-eye view" of the battlespace over Link 16, meaning other aircraft cannot leverage its sensor fusion14. Furthermore, if either stealth aircraft transmits over Link 16, they broadcast omnidirectional emissions that enemy signals intelligence can easily detect, functionally neutralizing their primary strategic advantage14. The DoD initially planned to retrofit the F-22 with MADL to solve this issue, but the program was abruptly canceled in 2010 due to cost overruns and technology maturity risks, cementing the stovepipe14. To resolve this Babel-like communication failure and begin constructing a rudimentary kill web, the defense industry had to engineer complex, multi-million-dollar gateways. Contractors developed software-defined radios, such as the Freedom 550, which act as flying translators capable of converting IFDL to MADL and routing data through J-series messages via Link 1615. These translating radios have been integrated into high-altitude uncrewed aerial vehicles like the RQ-4 Global Hawk, as well as the U-2S Dragon Lady spy plane equipped with the Hydra Open Systems Gateway (OSG) payload15. Through initiatives like Project Iguana and Project Hunter, these gateway aircraft have successfully demonstrated the ability to bridge the gap, allowing an F-35 to detect a simulated ballistic missile and pass the telemetry through a U-2 directly to ground-based command nodes16. Boeing has also developed the Talon HATE pod for the F-15 to perform similar datalink translation functions15. While functional, this gateway approach highlights the severe limitations of legacy procurement. The military is forced to launch additional, highly vulnerable aircraft simply to allow two of its most advanced fighters to share targeting data. The failure is not one of engineering negligence, but of a bureaucratic acquisition structure that prioritized platform-specific requirements over cross-domain network integration13. Joint Interface Control Officers (JICOs) spend immense effort attempting to optimize the joint datalink network, but they are severely constrained by the hardware13. The information available to a datalink is predetermined through bureaucratic modernization timelines and requirements definitions; if a platform's data bus has not been specifically programmed to share threat emission data, it cannot be transmitted over the datalink, regardless of whether a physical connection exists13.

PPBE and the "Color of Money": Financing Software at the Speed of Relevance

The transition from kill chains to kill webs is fundamentally a transition from hardware-defined warfare to software-defined warfare. Modern battle networks rely on high-throughput data integration, artificial intelligence (AI), machine learning (ML), and cloud computing to fuse intelligence, surveillance, target acquisition, and reconnaissance (ISTAR) data in real time20. However, the DoD's legacy financial framework—the Planning, Programming, Budgeting, and Execution (PPBE) process—was designed for buying physical assets, inherently treating software as an afterthought10.

The Barrier of Segregated Appropriations

The PPBE system dictates that funds be strictly categorized into different "colors of money," primarily Research, Development, Test, and Evaluation (RDT\&E); Procurement; and Operations and Maintenance (O\&M)22. In a traditional hardware program, an aircraft or tank is researched (RDT\&E), purchased (Procurement), and then flown and maintained (O\&M) in a neat, sequential waterfall23. Software, conversely, is never truly "finished"24. The Defense Innovation Board's seminal study on software acquisition explicitly highlighted that software development requires continuous, iterative cycles where prototyping, deployment, and sustainment occur simultaneously23. Attempting to buy agile software with rigid, sequential funding authorities has historically paralyzed defense IT modernization22. Because cyber threats and industry innovations evolve so rapidly, it is practically impossible for a program manager to forecast software needs one to two years in advance23. If a cyber defense unit identifies a critical vulnerability and needs to quickly decommission an obsolete software tool to procure a commercial replacement, they must transition from O\&M funds to Procurement funds. Doing so requires an "above-threshold reprogramming action," a bureaucratic maneuver requiring formal congressional approval that can delay deployment by months or even years23. By the time the funding is secured, the software may already be obsolete, the adversary's tactics may have shifted, or early adopters of fee-for-service cloud environments may find themselves burdened with unexpected, crippling costs10.

The Budget Activity 8 (BA-08) Pilot Solution

Recognizing this systemic financial friction, Congress and the DoD initiated the Budget Activity 8 (BA-08) Software and Digital Technology Pilot Program23. BA-08 is not a newly minted appropriation; rather, it consolidates RDT\&E, Procurement, and O\&M funding into a single budget activity housed under the RDT\&E umbrella, providing program managers with a unified, color-blind funding stream tailored for continuous software development22. The results of the BA-08 pilot underscore how deeply financial regulations impact tactical readiness and the ability to construct software-defined kill webs. The Project Manager for Defensive Cyber Operations (PM DCO) utilized BA-08 to rapidly procure software licenses, expand cloud hosting for the Army's Gabriel Nimbus big data platform, and deploy new analytics tools to the cyber battlefield without waiting for Congressional reprogramming approvals23. In one instance, based on direct feedback from cyber defenders, the DCO team realized a legacy software system was no longer effective. Utilizing BA-08, they immediately decommissioned the old system and procured a modern tool capable of indexing and correlating network data, executing a rapid pivot that bypassed the reprogramming threshold entirely and generated over $3 million in cost avoidance23. The PPBE Reform Commission, mandated by the National Defense Authorization Act (NDAA), recently published comprehensive findings echoing these successes. The Commission noted that the U.S. risks losing its technological edge without immediate transformational changes in resourcing, particularly in the year of execution10. The eventual goal of the acquisition community is for Congress to permanently establish this single appropriation category across all defense software portfolios, ensuring program managers can prioritize emerging technologies based on end-user needs rather than accounting constraints23.

The JADC2 Illusion: Decentralized Execution and Budgetary Opacity

To operationalize the kill web concept at a strategic level, the DoD has launched the Combined Joint All-Domain Command and Control (CJADC2) initiative27. CJADC2 is not a single, monolithic weapon system or a singular program of record; rather, it is a conceptual framework designed to link sensors from all military branches and allied partners into a unified, AI-powered network27. The ultimate objective is to achieve "decision superiority," shifting from a "swivel chair" model—where human operators manually re-type coordinates from one proprietary terminal to another—to a seamlessly integrated digital battlespace capable of executing algorithmic warfare21. However, the implementation of JADC2 exposes the deep fissures in the decentralized defense procurement process. Because the DoD historically lacked a centralized acquisition authority with the budget to enforce top-down cross-domain compliance, each branch of the military launched its own parallel initiative to contribute to JADC227.

The Government Accountability Office (GAO) has repeatedly criticized the DoD's handling of JADC2, noting that the department has struggled to define the scope, schedule, or comprehensive cost of the overarching effort30. Without a formalized framework to guide investments across portfolios, military departments are concurrently pursuing independent data integration capabilities28. This decentralization risks creating redundant programs that lack true interoperability, potentially requiring the department to purchase an endless series of expensive hardware and software patches simply to create workarounds between the Army, Navy, and Air Force systems33. Furthermore, the lack of budget transparency has drawn the ire of Congressional appropriators. JADC2 lacks a single dedicated program element in DoD budget justification books, making it exceedingly difficult to track the overall funding profile31. In recent fiscal years, JADC2 funding was briefed as approximately $1.4 billion, but this was a piecemeal compilation of branch-level projects, such as $66 million in RDT\&E for Project Convergence, $192 million for Project Overmatch, and $500 million for ABMS31. The Air Force's ABMS is currently the most transparent of the three, evolving from a traditional aircraft replacement program into a family of systems using non-traditional acquisition tools, but even ABMS has struggled to define exact delivery timelines30. Additionally, Continuing Resolutions (CRs), which freeze new program spending, routinely jeopardize the rollout of synchronized, combined JADC2 architectures, further stalling the realization of joint kill webs27. Overly restrictive data classification protocols also remain a significant hindrance, actively preventing the seamless sharing of command and control data across branch and coalition boundaries28.

Breaking Vendor Lock-In: MOSA and the Open DAGIR Framework

A primary reason historical attempts at building battle networks failed is that they attempted to construct monolithic architectures reliant on single prime contractors. To avoid repeating these failures, Congress and the DoD now legally mandate a Modular Open Systems Approach (MOSA) for new weapon systems35. MOSA requires programs to design systems with highly modular components and standardized, open interfaces35. Theoretically, this allows the government to "plug and play" new hardware or software from varying vendors without replacing the entire system, lowering sustainment costs and rapidly inserting commercial innovations35. However, translating MOSA from a legislative mandate into acquisition reality has proven extraordinarily difficult. The GAO found that out of 20 programs reviewed, none had conducted a formal analysis of costs and benefits for MOSA because DoD policy did not explicitly require one35. Program managers routinely fail to plan for MOSA due to the added upfront cost and time required to design open architectures35. Compounding the issue, Program Executive Offices lack formal processes to coordinate MOSA implementation across their portfolios, resulting in redundant development and missed opportunities to share modular solutions across different platforms35. Furthermore, existing DoD policies fail to adequately address how MOSA should be applied to rapid acquisition pathways, such as the Middle Tier of Acquisition (MTA), which aims to complete rapid prototyping in five years or less39.

The CDAO and the Data Imperative

A critical subset of the MOSA philosophy applies directly to data and software. Historically, the DoD has suffered from extreme vendor lock-in. A single prime contractor typically provides the compute platform, the developer environment, the proprietary application, and crucially, retains ownership over the underlying data structure41. In this model, the government must repeatedly pay the prime contractor to access, move, or analyze its own operational data, heavily stalling the integration of AI-driven kill webs41. To dismantle this paradigm, the DoD established the Chief Digital and Artificial Intelligence Office (CDAO)42. The CDAO is tasked with accelerating the adoption of data, analytics, and AI from the enterprise down to the tactical edge8. The office has initiated a series of "Pace-Setting Projects" (PSPs)—such as Swarm Forge, Agent Network, and Open Arsenal—designed to prototype AI agents for battle management and compress the intelligence-to-capability pipeline8. A major component of the CDAO’s strategy involves the Global Information Dominance Experiments (GIDE), a recurring series of quarterly exercises involving all combatant commands and international partners designed to iteratively test and scale data integration layers supporting CJADC229.

The Open DAGIR Architecture

The crown jewel of the CDAO’s acquisition strategy is the Open Data and Applications Government-owned Interoperable Repositories (Open DAGIR) framework41. Open DAGIR represents a fundamental paradigm shift in software architecture and acquisition strategy. It mandates that software systems be designed and procured in highly segregated layers, ensuring that choices made in one part of the technology stack do not trap the government into a single vendor for the rest of the stack41.

Under Open DAGIR, the government retains full, unencumbered ownership of the technology stack, the underlying data, and the APIs44. If an application layer fails to perform, or a commercial startup develops a superior AI targeting algorithm, the DoD can seamlessly rip out the legacy application and plug in the new software without having to modify the foundational data layer or pay extortionate integration fees to the original prime contractor41. By standardizing enterprise API interfaces and deploying federated data catalogs, Open DAGIR aims to create a highly competitive marketplace where commercial vendors can rapidly pilot, test, and scale AI-enabled battle management tools using live military data41. To facilitate this, the CDAO operates the Tradewinds Solutions Marketplace, a digital repository of post-competition, readily awardable pitch videos from traditional and non-traditional defense contractors45. This strategy treats data as a weaponized, interoperable asset rather than a proprietary byproduct of a hardware purchase, aligning acquisition directly with the requirements of a dynamic kill web21.

Middleware and Machine-to-Machine Integration: STITCHES and ACK

While Open DAGIR provides an elegant blueprint for future software acquisition, the DoD must still confront the reality of its existing inventory. The military operates thousands of legacy hardware platforms that were procured decades ago and were never designed for open architectures49. Replacing all legacy systems is financially and operationally impossible; furthermore, the original developers are often retired, and the source code or build configurations have been lost49. Consequently, the success of the kill web relies heavily on retrofitting interoperability at the tactical edge.

The STITCHES Toolchain

One of the most revolutionary approaches to solving this legacy interoperability crisis is a technology developed by the Defense Advanced Research Projects Agency (DARPA) called the System-of-systems Technology Integration Tool Chain for Heterogeneous Electronic Systems (STITCHES)50. Historically, integrating two incompatible systems required forcing them to adopt a common, global standard—a wildly expensive, slow process that inevitably lagged behind commercial technology49. STITCHES completely abandons the pursuit of a common standard49. Instead, STITCHES relies on a graph-based structure known as the Field and Transform Graph (FTG) that maps the interfaces of disparate systems49. When two incompatible systems need to communicate, STITCHES leverages the system specifications and modern compilation techniques to auto-generate a highly optimized, low-latency, and high-throughput executable binary—essentially bespoke, self-writing middleware—that translates data between the systems in real time49. Crucially, STITCHES requires no hardware upgrades, no modifications to existing proprietary software, and no common API49. Because the auto-generated code is tailored solely to the specific interaction requested, it removes unnecessary interaction paths, thereby increasing runtime performance and significantly decreasing the cybersecurity attack surface49. Because the relationships within the FTG are used compositionally, as more interfaces are added, vast interoperability can be achieved through linear, rather than exponential, work49. During Advanced Battle Management System (ABMS) demonstrations, STITCHES successfully linked air defense batteries, ships, and aircraft built decades apart, enabling machine-to-machine distributed fire control50. However, STITCHES perfectly illustrates the structural friction of legacy defense procurement. Because STITCHES acts as a software patch or middleware that sits in the "seams" between different weapons platforms, it does not naturally belong to any single Program Executive Office52. Without a dedicated PEO to sponsor its sustainment and fund the necessary "Software Engineering Squadrons" to implement it at scale, the program has frequently found itself at severe risk of slipping through the cracks of the acquisition bureaucracy52. Tim Grayson, director of DARPA's Strategic Technology Office, noted the bizarre nature of the challenge: the military desperately wants the capability to enable JADC2, but because the DoD's organizational structure is built to buy discrete endpoints, the "end user" for a decentralized middleware tool "does not fully exist"52.

Adapting Cross-Domain Kill-Webs (ACK)

Once systems are digitally connected via translation tools like STITCHES, commanders face the cognitive challenge of managing the sheer volume of options. To close the kill web at combat speed, DARPA introduced the Adapting Cross-Domain Kill-Webs (ACK) program4. ACK acts as an AI-driven decision aid that analyzes thousands of variables across all domains to recommend the optimal sensor-to-shooter pairing4. ACK functions akin to a commercial e-commerce algorithm, utilizing a "Capability Marketplace" where diverse military assets submit "bids and offers" to service targets4. This abstraction is critical for joint operations. Providers can offer their capabilities based on the specific effects they achieve, rather than revealing highly classified technical parameters, allowing cross-domain adaptation while protecting sensitive sources and methods4. During live demonstrations, the ACK software analyzed vast arrays of cross-domain kill web configurations, selected the optimal command-and-control "play," and transmitted machine-to-machine instructions to ground-based fire control systems to automatically scramble interceptors50. Together, technologies like STITCHES and ACK demonstrate that the technical capability to build adaptive kill webs currently exists; the barrier remains the institutional capability to procure, scale, and sustain them20.

Reforming the Software Acquisition Workforce and Security Paradigms

To overcome the architectural friction plaguing defense procurement, the DoD must rethink its relationship with the defense industrial base, the structure of its workforce, and the security paradigms dictating software deployment.

Redefining the Acquisition Workforce

The DoD relies heavily on an acquisition workforce trained in hardware lifecycle management. These professionals often struggle with the nuances of agile software development, leading to "frustratingly fuzzy" requirements and misaligned expectations24. The RAND Corporation conducted a comprehensive review of software acquisition competencies and found a critical gap: there is no currently accepted government job title or occupational series specifically for software professionals54. RAND developed a model comprising 48 distinct technical competencies—spanning software construction management, system architecture design, and mission assurance—that the DoD must validate and integrate to properly size, train, and incentivize its workforce54. Without a workforce fluent in interpreting Software Bills of Materials (SBOMs), managing active cyber defenses, and overseeing DevSecOps environments, the military cannot effectively partner with commercial industry or manage the software supply chain12.

The Software Acquisition Pathway and Continuous Security

To bypass the lethargic milestones of traditional acquisition, the DoD introduced the Software Acquisition Pathway (SWP)26. The SWP allows program managers to utilize modern software development techniques to deliver value at the pace of relevance. According to the GAO, 75 to 80 percent of Major Defense Acquisition Programs (MDAPs) have adopted modern development practices like Agile and DevSecOps, with many delivering software capabilities in less than four months26. However, deploying software at the speed of relevance requires dismantling the legacy security accreditation process. Traditional security accreditation relies on a static Authority to Operate (ATO), a paper-heavy process that assumes a system is "complete" and will not change24. For kill webs to function, they must continuously ingest new algorithms, threat signatures, and API integrations7. To solve this, the DoD is moving toward a Continuous Authority to Operate (cATO) framework24. By establishing accredited software factories that utilize automated DevSecOps pipelines, programs can deploy critical software updates and patches instantly, responding to newly identified vulnerabilities or shifting battlefield conditions without bureaucratic delays24.

Conclusion

The legacy defense procurement process is struggling to build kill webs because it remains an industrial-age apparatus tasked with executing an information-age strategy. The structural biases of the Planning, Programming, Budgeting, and Execution (PPBE) system, the strict demarcation of funding categories, and the siloed nature of Program Executive Offices actively reward the acquisition of closed, proprietary hardware platforms while penalizing continuous, cross-domain software integration. The inability of advanced platforms like the F-22 and F-35 to natively share data without vulnerable gateway aircraft is a direct symptom of this fragmented approach. Transitioning from linear kill chains to dynamic, multi-domain kill webs requires more than just the insertion of artificial intelligence; it requires the Department of Defense to fundamentally decouple software acquisition from hardware constraints. By expanding agile funding authorities like the BA-08 pilot, enforcing strict data ownership models via the Open DAGIR framework, and scaling autonomous, non-proprietary integration tools like STITCHES, the defense establishment can break the cycle of vendor lock-in and stovepiped development. Only by aligning its financial, organizational, and workforce incentives with the realities of software-defined warfare can the military construct the resilient, adaptive battle networks required to maintain decision superiority in the twenty-first century.

Works cited

1. From Platforms to Ecosystems: Turkiye's Architecture Test | TURDEF, https://turdef.com/article/from-platforms-to-ecosystems-turkiye-s-architecture-test

2. Realising a data-centric all-domain kill-web through network-driven system design, https://theforge.defence.gov.au/war-college-papers-2022/realising-data-centric-all-domain-kill-web-through-network-driven-system-design

3. Transitioning from the kill chain to the kill web \- Military Embedded Systems, https://militaryembedded.com/comms/communications/transitioning-from-the-kill-chain-to-the-kill-web

4. ACK \- DARPA, https://www.darpa.mil/research/programs/adapting-cross-domain-kill-webs

5. Mosaic Warfare In Ukraine \- The Defence Horizon Journal, https://tdhj.org/blog/post/mosaic-warfare-ukraine/

6. Drones & Counter-Drone Systems \- CAPSS India, https://capssindia.org/wp-content/uploads/2023/07/New-Delhi-Ppaer-No.-10-Gp-Capt-Amitabh-Mathur.pdf

7. The New Battlespace: How Geospatial AI Is Reshaping Military Intelligence, https://projectgeospatial.org/geospatial-frontiers/the-new-battlespace-how-geospatial-ai-is-reshaping-military-intelligence

8. Chief Digital and Artificial Intelligence Office, https://www.ai.mil/

9. Battle Networks and the Future Force \- CSIS, https://www.csis.org/analysis/battle-networks-and-future-force-0

10. COMMISSION ON PPBE REFORM \- Defense Management Institute, https://www.dmi-ida.org/download-pdf/pdf/03052024\_ppbe.pdf

11. Ideas & Issues \- Marine Corps Association, https://www.mca-marines.org/magazine-tag/ideas-issues/page/2/

12. Improving Defense Acquisition: Insights from Three Decades of RAND Research, https://www.rand.org/pubs/research\_reports/RRA1670-1.html

13. MITCHELL INSTITUTE Policy Paper, https://www.mitchellaerospacepower.org/app/uploads/2021/07/Speed\_Is\_Life\_Policy\_Paper\_28-FINAL.pdf

14. 5th Generation Comms | Air & Space Forces Magazine, https://www.airandspaceforces.com/article/the-f-22-and-the-f-35-are-struggling-to-talk-to-each-other-and-to-the-rest-of-usaf/

15. Northrop's fix for F-35 and F-22 communications problem involves Global Hawk drones, https://www.defensenews.com/air/2017/08/23/northrops-fix-for-f-35-and-f-22-communications-problems-involves-global-hawk-uavs/

16. F-22 And F-35 Datalinks Finally Talk Freely With Each Other Thanks To A U-2 Flying Translator \- TWZ, https://www.twz.com/40380/f-22-and-f-35-datalinks-finally-talk-freely-with-each-other-thanks-to-a-u-2-flying-translator

17. Multifunction Advanced Data Link \- Wikipedia, https://en.wikipedia.org/wiki/Multifunction\_Advanced\_Data\_Link

18. Northrop Grumman-Developed Stealthy Data Link Validated as Combat Ready with US Marine Corps, https://investor.northropgrumman.com/news-releases/news-release-details/northrop-grumman-developed-stealthy-data-link-validated-combat

19. In First, Air Force Will Send Secure Data Between an F-22 and F-35 \- Military.com, https://www.military.com/daily-news/2019/11/08/first-air-force-will-send-secure-data-between-f-22-and-f-35.html

20. Fighting for Information: A Theory of Tactics for the Next Army \- CSIS, https://www.csis.org/analysis/fighting-information-theory-tactics-next-army

21. A PARADIGM SHIFT FOR THE UK STRATEGIC DEFENCE REVIEW \- CHACR, https://chacr.org.uk/wp-content/uploads/2024/12/The-Battleweb.pdf

22. Michael Obadal: Army to Issue New Software Directive \- ExecutiveGov, https://www.executivegov.com/articles/army-software-directive-budget-activity-8

23. THE CYBER EXPERIMENT \- U.S. Army Acquisition Support Center, https://asc.army.mil/web/news-the-cyber-experiment/

24. Software Defines Tactics: Structuring Military Software Acquisitions for Adaptability and Advantage in a Competitive Era \- Amazon S3, https://s3.amazonaws.com/media.hudson.org/Software+Defines+Tactics.pdf

25. PILOT IS PARAMOUNT | Article | The United States Army, https://www.army.mil/article/276687/pilot\_is\_paramount

26. The State of DevSecOps | March 2025, https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsStateOf.pdf

27. Joint All-Domain Command and Control \- Wikipedia, https://en.wikipedia.org/wiki/Joint\_All-Domain\_Command\_and\_Control

28. GAO-25-106454, DEFENSE COMMAND AND CONTROL: Further Progress Hinges on Establishing a Comprehensive Framework, https://www.gao.gov/assets/gao-25-106454.pdf

29. Chief Digital and Artificial Intelligence Office \> Initiatives \> CJADC2, https://www.ai.mil/Initiatives/CJADC2/

30. Battle Management: DOD and Air Force Continue to Define Joint Command and Control Efforts | U.S. GAO, https://www.gao.gov/products/gao-23-105495

31. Lifting the Fog of War | Federal Budget IQ, https://federalbudgetiq.com/insights/lifting-the-fog-of-war/

32. Project Convergence: Achieving Overmatch by Solving Joint Problems \- NDU Press, https://ndupress.ndu.edu/Media/News/News-Article-View/Article/2807194/project-convergence-achieving-overmatch-by-solving-joint-problems/

33. Mission (Command) Complete: Implications of JADC2 \- NDU Press, https://ndupress.ndu.edu/Media/News/News-Article-View/Article/3841502/mission-command-complete-implications-of-jadc2/

34. GAO-23-105495, BATTLE MANAGEMENT: DOD and Air Force Continue to Define Joint Command and Control Efforts, https://www.gao.gov/assets/gao-23-105495.pdf

35. GAO-25-106931, WEAPON SYSTEMS ACQUISITION: DOD Needs Better Planning to Attain Benefits of Modular Open Systems, https://www.gao.gov/assets/gao-25-106931.pdf

36. DOD Needs Better Planning to Attain Benefits of Modular Open Systems \- GAO, https://files.gao.gov/reports/GAO-25-106931/index.html

37. Weapon Systems Acquisition: DOD Needs Better Planning to Attain Benefits of Modular Open Systems | U.S. GAO, https://www.gao.gov/products/gao-25-106931

38. GAO MOSA Report, https://mosa.net/2025/01/27/gao-mosa-report/

39. GAO: DoD Needs Better Planning of 'Plug-and-Play' Weapons Management Systems, https://www.meritalk.com/articles/gao-dod-needs-better-planning-of-plug-and-play-weapons-management-systems/

40. Weapon Systems Testing: Reorganization of DOD's Office of the Director, Operational Test and Evaluation | U.S. GAO, https://www.gao.gov/products/gao-26-108859

41. Open DAGIR Framework | AI Exchange Portal, https://cdao-test.azurewebsites.us/policies-guidance-best-practice/frameworks/open-dagir-framework/

42. Organization \- Chief Digital and Artificial Intelligence Office, https://www.ai.mil/About/Organization/

43. Chief Digital & Artificial Intelligence Office Celebrates First Year \- Department of War, https://www.war.gov/News/Releases/Release/Article/3464012/chief-digital-artificial-intelligence-office-celebrates-first-year/

44. Open DAGIR, https://media.defense.gov/2024/Oct/27/2003571833/-1/-1/0/2024-07-18-CDAO-OPEN-DAGIR-FACT-SHEET.PDF

45. CDAO Announces New Approach to Scaling Data, Analytics and AI Capabilities, https://www.war.gov/News/Releases/Release/Article/3791829/cdao-announces-new-approach-to-scaling-data-analytics-and-ai-capabilities/

46. Open DAGIR Overview, https://www.ai.mil/Portals/137/Documents/Resources%20Page/2025-01-Open-DAGIR-Overview.pdf?ver=UwgZcW-VUj0wqeHuXbPosQ%3D%3D

47. Open DAGIR \- Chief Digital and Artificial Intelligence Office, https://www.ai.mil/Initiatives/Open-DAGIR/

48. AI, Innovation, and Acquisition: Emerging Trends and How to Work with DoD \- Veteran Institute for Procurement, https://nationalvip.org/assets/pdf/session-4-emerging-trends.pdf

49. STITCHES \- Apogee Research, https://apogee-research.com/stitches/

50. Creating Cross-Domain Kill Webs in Real Time \- DARPA, https://www.darpa.mil/news/2020/cross-domain-kill-webs

51. Real time cross-domain kill webs \-- ACK and STITCHES \- Acquisition Talk, https://acquisitiontalk.com/2020/09/real-time-cross-domain-kill-webs-ack-and-stitches/

52. DARPA program that could enable JADC2 at risk of slipping through the bureaucratic cracks, https://fedscoop.com/stitches-darpa-program-jadc2-network-connector-falling-through-cracks/

53. DARPA STITCHES Program to Deliver Data Sharing Capabilities for JADC2; Tim Grayson Quoted \- ExecutiveGov, https://www.executivegov.com/articles/darpa-stitches-program-to-deliver-data-sharing-capabilities-for-jadc2-tim-grayson-quoted

54. Software Acquisition Workforce Initiative for the Department of Defense \- RAND, https://www.rand.org/pubs/research\_reports/RR3145.html

55. 2 Army Programs Ready for DOD's Software Acquisition Pathway \- IPPS-A, https://ipps-a.army.mil/Resources/News/Article/4141854/2-army-programs-ready-for-dods-software-acquisition-pathway/