The Architecture of Decision-Centric Warfare: Engineering the Transition from Kill Chains to Cross-Domain Kill Webs

The Architecture of Decision-Centric Warfare: Engineering the Transition from Kill Chains to Cross-Domain Kill Webs

The strategic calculus of global military conflict is undergoing a fundamental realignment. For decades, the projection of military power relied heavily on the deployment of exquisite, monolithic platforms—stealth bombers, aircraft carriers, and advanced armored vehicles—operating within rigid, highly structured operational architectures. These architectures, while highly optimized for their specific environments, are increasingly vulnerable to the realities of modern great power competition. Peer and near-peer adversaries have spent decades observing these systems, subsequently developing sophisticated Anti-Access/Area Denial (A2/AD) envelopes, advanced electronic warfare (EW) capabilities, and "systems destruction" doctrines explicitly designed to sever the delicate informational links that bind traditional forces together1. To survive and dominate in this contested, data-saturated future battlespace, the overarching paradigm of military operations is shifting from the traditional, linear "kill chain" to the dynamic, resilient "kill web"4. This transition is not merely a software upgrade; it is a profound doctrinal evolution toward what military strategists term "decision-centric warfare"6. Operational success will no longer belong solely to the force with the most advanced kinetic effectors, but to the force that can aggregate data, orchestrate distributed assets, and execute decisions faster than the adversary can orient to the threat8. Achieving this vision requires an unprecedented synthesis of hardware engineering, software architecture, and artificial intelligence. The technical backbone of a functioning military kill web relies on establishing hardware modularity at the tactical edge, deploying self-healing mesh networks to overcome bandwidth and latency constraints, and utilizing auto-generating middleware to translate proprietary data standards on the fly9. Above this physical layer, sophisticated battle management algorithms—most notably developed under the Defense Advanced Research Projects Agency (DARPA) Adapting Cross-Domain Kill-Webs (ACK) program—must function as capability marketplaces, instantly pairing sensors and shooters across disparate military branches4. This comprehensive report examines the strategic imperatives driving the transition to the kill web, details the core technical requirements necessary for its implementation, explores the algorithmic orchestration of multi-domain assets, and critically assesses the ongoing bureaucratic, cybersecurity, and doctrinal vulnerabilities challenging the realization of the Combined Joint All-Domain Command and Control (CJADC2) framework.

The Doctrinal Imperative: Abandoning the Linear Kill Chain

To articulate the necessity of the kill web, it is essential to first understand the mechanics and inherent fragilities of the legacy kill chain. The traditional targeting process is a linear sequence, often codified in military doctrine as the F2T2EA cycle: Find, Fix, Track, Target, Engage, and Assess1. In this industrial-era model, operations are "forecast-centric." Military planners anticipate specific operational gaps and engineer narrowly scoped, tightly coupled systems to fill them6. In a traditional kill chain, a specific sensor (e.g., a ground-based early warning radar) is physically and digitally hardwired to communicate with a specific analytical command node, which is in turn pre-programmed to pass firing coordinates to a specific effector (e.g., an interceptor missile battery)12. While this linear progression is highly efficient in permissive environments, it relies on numerous assumptions and features single points of failure. If an adversary utilizes electronic attack to jam the specific radio frequency linking the radar to the command node, or uses a kinetic strike to destroy the command post itself, the entire chain is broken2. The sensor cannot organically discover another shooter, and the shooter remains blind without its designated sensor.

Mosaic Warfare and Decision-Centric Operations

The kill web abandons this linearity in favor of a networked ecosystem. Rather than a pre-defined path from a single sensor to a single shooter, a kill web establishes a distributed combat cloud where any sensor can cue any effector, across any domain, dynamically orchestrated by intelligent software4. This conceptual shift is the bedrock of the "Mosaic Warfare" strategy developed by DARPA and expanded upon by the Center for Strategic and Budgetary Assessments (CSBA). Mosaic Warfare posits that by disaggregating forces—breaking down monolithic platforms into a larger number of smaller, less expensive, and highly interoperable manned and autonomous units—a military can achieve "heterogeneity at scale"5. Much like individual ceramic tiles can be arranged to form infinite patterns, these disaggregated assets can be rapidly composed and recomposed into adaptive force packages tailored to the immediate tactical environment16. The strategic objective of the kill web is to generate an "optionality advantage"18. In decision-centric operations, commanders prioritize resilience over pure efficiency. By possessing a vast, decentralized network of sensors and shooters, the commander retains multiple viable courses of action even as the adversary attrites individual nodes6. If a primary satellite uplink is destroyed, the network immediately and autonomously routes targeting data through a nearby loitering drone or a naval vessel's communication relay19. For the adversary, this creates an unsolvable mathematical dilemma; the sheer volume of potential operational pathways overwhelms their ability to predict, preempt, or defend against an attack7.

Backbone Engineering: Hardware, Edge Computing, and Transport

Translating the theoretical kill web into a functional architecture requires solving massive engineering bottlenecks at the physical and transport layers. A kill web cannot function on legacy, proprietary systems that require years of bespoke engineering to integrate. It requires a baseline of interoperable hardware, the capacity to process data at the extreme tactical edge, and low-latency networks capable of surviving electromagnetic saturation.

The Modular Open Systems Approach (MOSA)

For decades, the defense industrial base operated on a model of vendor lock-in. Prime contractors delivered closed systems where the hardware, software, and middleware were tightly coupled and fiercely protected as proprietary intellectual property22. If the military wanted to upgrade a sensor or integrate a new communication link, they were forced to return to the original manufacturer for a costly and time-consuming redesign. To enable the rapid composability required by the kill web, the Department of Defense (DoD) mandated the Modular Open Systems Approach (MOSA) across all new acquisitions10. MOSA is not a single technology, but a legislative and engineering strategy that dictates that defense systems must be constructed from separable modules connected via open, consensus-based standards24. Under the MOSA umbrella, several specific technical standards have emerged to govern the physical layer of the kill web. The foundational standard is OpenVPX (VITA 65), which defines the physical chassis, backplanes, power distribution, and high-speed serial interconnects (such as 100 Gigabit Ethernet and PCIe Gen 4\) for ruggedized defense electronics10. Building directly upon OpenVPX is the Sensor Open Systems Architecture (SOSA). SOSA establishes rigorous guidelines for plug-in cards (PICs) used in Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance, and Reconnaissance (C5ISR) systems11. By defining strict slot profiles and pinouts, SOSA allows an engineer to remove an aging electronic warfare module from an Air Transport Rack (ATR) and replace it with a state-of-the-art processor from a completely different manufacturer, ensuring hardware-level interoperability without a complete system overhaul24. Table 1 summarizes the primary architectural standards driving physical and software interoperability within the kill web:

Edge Computing and Preventing Analytical Saturation

The transition to a multi-domain sensor grid introduces a severe risk of analytical and spectrum saturation30. Modern sensors—such as synthetic aperture radar (SAR), full-motion video, and signals intelligence (SIGINT) arrays—generate terabytes of data. Attempting to pipe all this raw data back to a centralized cloud command center for processing is structurally impossible in a contested environment where adversaries actively jam satellite and radio frequencies3. Consequently, the kill web relies heavily on edge computing. By embedding high-performance computing directly alongside the sensor—often utilizing SOSA-aligned 3U or 6U VPX cards equipped with commercial-grade Graphics Processing Units (GPUs) like the NVIDIA RTX series or Intel Xeon processors—raw data is processed at the point of collection11. AI algorithms executing on these edge nodes analyze the imagery or electronic emissions locally, isolating the critical targeting metadata (e.g., the exact coordinates of an enemy surface-to-air missile launcher)13. Rather than transmitting gigabytes of video over a degraded link, the edge node transmits only a few kilobytes of actionable intelligence, preserving critical bandwidth and accelerating the kill web's closure time30.

Latency Thresholds and Tactical Data Links

For high-speed intercepts, such as defending against hypersonic cruise missiles or coordinating drone swarms, the latency between sensor detection and effector launch must be minimized. The backbone of the kill web requires network updates to occur with latencies of less than one millisecond, exclusive of the physical propagation time of the signal in space30. Traditional tactical data links, while secure, often fail to meet the dynamic routing requirements of the kill web. Systems like the Multifunction Advanced Data Link (MADL) or the Common Data Link (CDL) frequently rely on linear, daisy-chain network topologies. While functional for small formations, scaling these linear networks across thousands of multi-domain nodes introduces unacceptable latency spikes, as data must be sequentially processed and relayed over multiple hops33. To overcome this, the kill web requires robust, self-healing mesh networks. Technologies such as the Tactical Targeting Network Technology (TTNT) waveform provide high-throughput, low-latency mesh architectures34. In a mesh topology, data does not rely on a single, linear path. If a communication relay node is destroyed by enemy fire, the network automatically and instantaneously reroutes the data through surviving nodes, maintaining the integrity of the kill web in highly attritable environments19. Table 2 highlights the differences between prominent tactical data links and their integration into the kill web:

The Software Layer: Universal Standards vs. Auto-Generated Middleware

Hardware modularity and mesh networking provide the physical pathways, but the disparate systems inhabiting the kill web must possess a shared mechanism for understanding the data being transmitted. Historically, achieving software interoperability across the Department of Defense has been a highly complex and deeply flawed endeavor.

The Push for Universal Standards: OMS and UCI

The traditional approach to software interoperability is the mandate of universal data standards. The Open Mission Systems (OMS) initiative represents a significant effort to standardize the interfaces between software services and hardware subsystems24. OMS provides an abstraction layer that decouples mission software from the underlying proprietary hardware, enabling rapid technical refresh24. Within the OMS framework operates the Universal Command and Control Interface (UCI). UCI is an XML-based schema that establishes a standardized set of messages for machine-to-machine, mission-level command and control38. UCI standardizes how systems request tasks, report capabilities, and share track data. For example, if an autonomous drone needs to transmit the coordinates of an identified target to an airborne command center, it formats that data according to the UCI schema, ensuring the receiving system can parse and understand the information27.

The Translation Dilemma and DARPA's STITCHES

While open standards like UCI are highly effective for new acquisitions, they present a monumental challenge for legacy systems. The U.S. military operates trillions of dollars of equipment deployed decades ago. Upgrading the core software of a legacy radar system or a Cold War-era bomber to natively speak a modern XML schema like UCI is often cost-prohibitive, technically risky, and requires lengthy recertification22. Furthermore, universal standards are inherently rigid; when a new weapon system requires a novel data field not supported by the standard, the standard must be updated, forcing every system in the ecosystem to upgrade simultaneously to maintain compatibility22. Recognizing that a universal standard is not a panacea for immediate operational interoperability, DARPA developed a revolutionary software toolchain: the System-of-systems Technology Integration Tool Chain for Heterogeneous Electronic Systems (STITCHES)9. STITCHES upends traditional software engineering by proving that systems do not need to share a common API or a universal standard to interoperate22. Instead of forcing systems to adapt to a standard, STITCHES leverages a graph structure known as the Field and Transform Graph (FTG). The FTG maps the specific input and output specifications of disparate systems22. Utilizing modern compilation techniques, STITCHES automatically generates a bespoke, executable binary patch—a piece of extremely low-latency, high-throughput middleware—that translates data between the systems on the fly9. Because STITCHES generates this code automatically without requiring human engineers to manually write interfaces, and because it does not require breaking into the existing source code of the legacy systems, integration timelines are compressed from years to mere months or days9. Furthermore, because the auto-generated code is tailored strictly to the required interaction, it eliminates unnecessary code bloat and reduces the cyber-attack surface22. The efficacy of STITCHES was decisively proven during the Air Force's Advanced Battle Management System (ABMS) on-ramp demonstrations in late 2020\. During a live-fire air defense scenario, STITCHES provided the critical machine-to-machine middleware connecting the modern C2 Incident Management Emergency Response Application (C2IMERA) with a legacy ground-based Composite Tracker and Classifier (CTC). This auto-generated translation enabled automated messaging over Link-16, successfully scrambling fighters to intercept simulated cruise missiles at combat speed9.

Orchestrating the Web: Capability Marketplaces and 4D Deconfliction

Assuming the hardware is modular, the networks are resilient, and the software can seamlessly translate data, a fundamental cognitive challenge remains: How does a human commander manage a disaggregated kill web containing tens of thousands of potential sensor-and-shooter combinations? The combinatorial explosion of options in a multi-domain environment far exceeds the analytical capacity of human staff utilizing traditional planning cycles4.

The Adapting Cross-Domain Kill-Webs (ACK) Program

To solve the orchestration bottleneck, DARPA initiated the Adapting Cross-Domain Kill-Webs (ACK) program. ACK functions as a decentralized, AI-driven decision aid designed to rapidly identify, evaluate, and select the optimal assets for target engagement across organizational and domain boundaries4. ACK reimagines military resource allocation by adapting algorithms originally developed for commercial e-commerce and online auctions4. The battlespace is structured as a massive "Capability Marketplace." Rather than viewing a naval destroyer purely as a maritime asset, the marketplace views it as a supplier of specific services—such as long-range radar tracking or Tomahawk strike capabilities4. When a tactical requirement arises, the ACK system broadcasts the need into the marketplace. Available assets—whether they belong to the Army, Navy, Air Force, or Space Force—computationally "raise their hands" to bid on the task43. This allows the kill web to capitalize on latent capacity. A Special Operations team requiring immediate suppressive fire might be seamlessly paired with an Air Force bomber orbiting miles away, bypassing traditional, sluggish hierarchical request processes43. To make this marketplace function, ACK must overcome deep-seated organizational friction. Each military domain possesses its own authorities, chains of command, and primary mission sets. Diverting a sensor from its primary mission to support a cross-domain request carries a distinct opportunity cost4. ACK addresses this through a "Virtual Liaison" service abstraction. The Virtual Liaison utilizes a common bid and offer language to rapidly calculate the value trade-offs of supporting a new mission versus maintaining the current one4. Given a diverse set of options, the algorithm assesses processing capacity, bandwidth availability, weapon range, and probability of kill, ultimately presenting the human commander with the highest-value command-and-control "play" to authorize4.

ASTARTE: Deconflicting the Autonomous Battlespace

Dynamic, cross-domain pairing introduces a severe physical hazard: airspace deconfliction. If an algorithm suddenly pairs an Army long-range artillery battery with a target, while simultaneously routing an Air Force unmanned aerial vehicle (UAV) through the same sector to provide damage assessment, the risk of fratricide or mid-air collision is exceptionally high45. The ACK program deliberately abstracts this flight-planning problem, necessitating a parallel algorithmic solution43. To provide the traffic control logic for the kill web, DARPA developed the Air Space Total Awareness for Rapid Tactical Execution (ASTARTE) program43. ASTARTE is an automated flightpath-planning engine designed to integrate with existing command structures, such as the Army’s Integrated Mission Planning and Airspace Control Tools (IMPACT) software45. ASTARTE utilizes AI to maintain a continuously updating, real-time, four-dimensional (space and time) moving picture of the battlespace. When the ACK marketplace generates a kill web pairing that requires airspace transit, ASTARTE instantly calculates complex route alternatives46. It routes friendly missiles, artillery trajectories, and autonomous aircraft through permissive airspace corridors, ensuring deconfliction while actively avoiding known enemy air defense envelopes45. By automating airspace coordination measures (ACMs), ASTARTE eliminates the procedural burden and human error that typically slows down joint fire execution, allowing the kill web to close at machine speeds46.

The CJADC2 Enterprise and the Software Backbone

The integration of these theoretical concepts, hardware standards, and AI algorithms is governed by the Department of Defense's Combined Joint All-Domain Command and Control (CJADC2) strategy. CJADC2 is not a single system or a specific piece of software; it is a unifying concept and architecture designed to ensure that the disparate modernization efforts of the individual military branches culminate in a truly interoperable joint force12. Despite the "Joint" mandate, the military branches initially approached network modernization through highly siloed initiatives. The Air Force developed the Advanced Battle Management System (ABMS), focusing heavily on cloud infrastructure and aerial data links15. The Navy launched Project Overmatch, prioritizing the integration of surface fleets, submarines, and unmanned maritime assets15. The Army initiated Project Convergence to weave together long-range precision fires and ground sensors, while the Marine Corps established Project Dynamis to adapt CJADC2 concepts for agile, stand-in forces operating at the extreme tactical edge48. Table 3 outlines the distinct service-level initiatives contributing to the CJADC2 framework:

The Maven Smart System and the "Ontology"

To prevent these service-specific initiatives from cementing into a new generation of disconnected stovepipes, the DoD requires an enterprise-wide software layer capable of fusing the data into a single Common Operational Picture (COP). Increasingly, the DoD has relied upon the Maven Smart System (MSS)—developed primarily by Palantir Technologies—to serve as the de facto backbone of CJADC253. Originating from Project Maven—an effort to apply computer vision and machine learning to analyze drone surveillance footage—MSS has expanded into a massive data integration and decision support platform55. MSS ingests telemetry from satellites, radars, and ground forces, processes it through complex algorithms, and presents commanders with a unified interface where enemy targets and friendly units are clearly delineated57. Recent iterations of MSS have integrated Large Language Models (LLMs) running in classified environments, allowing analysts to query the battlespace via natural language and task autonomous agents to generate operational courses of action57. The underlying architecture of MSS relies heavily on the concept of an "Ontology"—a structured, semantic data model that standardizes how different entities (e.g., a satellite image, a tank, a unit) relate to one another58. By mapping all incoming military data to this ontology, Palantir's software can rapidly correlate disparate intelligence feeds and power advanced AI applications58.

The Ontology Trap and the Vulnerability of Centralization

While systems like MSS provide unprecedented analytical power, they introduce profound strategic and structural vulnerabilities. Critics within the defense technology sector warn of the "Ontology Trap"31. By requiring the DoD to map its vast intelligence apparatus to a proprietary commercial ontology, the vendor effectively captures the logic layer of the military's decision-making process. The government retains ownership of the raw data, but loses the ability to seamlessly interpret or manipulate that data without the vendor's software, creating a severe form of vendor lock-in31. Furthermore, centralized platforms like MSS and Anduril's Lattice OS are heavily optimized for "data-rich" environments, assuming the presence of stable, high-bandwidth cloud connectivity (e.g., Starlink or hardened military SATCOM)3. In a high-intensity conflict against a peer adversary, this assumption is fatally flawed. Adversaries will systematically attack the transport layer, utilizing electronic warfare to jam satellite uplinks and kinetic strikes to destroy fiber-optic landing stations14. When network connectivity degrades to mere kilobits per second, centralized cloud architectures collapse31. To survive, the kill web must avoid the allure of total centralization3. It must prioritize true Edge AI—pushing lightweight, sovereign models directly onto the tactical nodes (the individual drone, the dismounted soldier, the mobile artillery piece) so they can process data and execute targeting logic locally, even when entirely severed from the broader strategic network3.

Bureaucratic Friction: GAO Findings on CJADC2

Beyond technical vulnerabilities, the implementation of CJADC2 faces significant bureaucratic friction. A highly critical report by the Government Accountability Office (GAO), designated GAO-25-106454, concluded that while the DoD has effectively championed the concept of CJADC2, it has utterly failed to establish a comprehensive framework to guide investments, track progress, or enforce interoperability60. The GAO noted that in the absence of an overarching enforcement mechanism, the military branches continue to develop their command and control projects largely in isolation60. The report highlighted that analysts are still frequently forced into "swivel chair" operations—manually reading data from one branch's proprietary system and physically typing it into another's, entirely defeating the purpose of machine-to-machine kill web integration61. Furthermore, the GAO identified overly restrictive and fragmented data classification policies as one of the most severe barriers to sharing C2 data, noting that the agencies building CJADC2 often lack the authority to force cross-classification data transfers61. Table 4 summarizes the primary bureaucratic and structural challenges facing CJADC2 implementation:

Software Vulnerabilities and the Ethics of Machine Speed

The transition from heavily armored, disconnected platforms to a software-defined kill web shifts the adversary's target from the physical domain to the digital domain. The very connectivity that provides the kill web its power is its most critical attack surface.

Cybersecurity and Supply Chain Vulnerabilities

As the DoD embraces modern software development practices—including agile CI/CD pipelines and the widespread use of open-source frameworks—it exposes the kill web to sophisticated supply chain attacks. Adversaries no longer wait to attack software in production; they target the developer's environment65. Recent cybersecurity incidents highlight this vulnerability. Malicious actors have successfully injected self-replicating worms—such as the Shai Hulud malware—into widely used open-source NPM packages66. Once a developer inadvertently downloads the compromised package during the build process, the malware executes, harvesting API keys, cloud access tokens, and proprietary source code66. If such a vulnerability propagates into the middleware (such as the binary patches generated by STITCHES) or the AI models orchestrating the capability marketplace, an adversary could subtly alter target prioritization, misroute data, or exfiltrate the cryptographic keys securing the mesh network67. Securing the kill web requires shifting vulnerability scanning directly into the Integrated Development Environment (IDE), neutralizing threats before they enter the military supply chain65.

Mission Command and Autonomous Lethality

Perhaps the most profound implication of the kill web is its impact on the ethics and doctrine of lethal force. The traditional paradigm of a "human-in-the-loop"—where a human operator manually reviews intelligence, verifies a target, and authorizes weapon release—is structurally incompatible with the speed of AI-driven warfare8. If an adversary launches a swarm of hundreds of autonomous loitering munitions, human cognitive processing is simply too slow to orchestrate an effective defense20. This reality forces a transition toward "human-on-the-loop" or supervisory control68. In this model, human commanders define the broad parameters of the mission, establish geofences and rules of engagement, and then authorize the AI (utilizing systems like ACK and MSS) to autonomously select targets and execute the firing sequence across the kill web54. The human's role shifts from an active participant to a supervisor who intervenes only to abort anomalous actions (command by negation)8. The DoD has attempted to regulate this shift through the continuous updating of DoD Directive 3000.09, "Autonomy in Weapon Systems," which mandates rigorous testing, verification, and human oversight for autonomous lethality54. However, the tension remains acute. Delegating the kill chain to algorithms risks automation bias, where operators inherently trust machine outputs even when the AI hallucinates or is deceived by adversarial data poisoning57. Preserving ethical clarity, accountability, and disciplined mission command in an era where the software—not just the drone—is the weapon system, remains the ultimate operational challenge of the 21st century54.

Conclusion

The transition from the linear kill chain to the networked kill web represents a foundational reimagining of how military power is organized, communicated, and applied. Driven by the necessity to survive in heavily contested, A2/AD environments, the U.S. military is abandoning brittle, forecast-centric architectures in favor of the dynamic, resilient principles of Mosaic Warfare. By networking sensors and shooters across all domains, the kill web generates a mathematically overwhelming array of options, turning operational complexity into a decisive strategic advantage. Realizing this architecture requires conquering immense technical challenges. The physical integration of the force depends on the strict adherence to hardware standards like SOSA and OpenVPX, enabling plug-and-play modularity and empowering AI processing at the extreme tactical edge. Overcoming the limits of legacy software demands novel approaches, utilizing tools like STITCHES to auto-generate translation middleware on the fly, bypassing the need for impossible universal data mandates. Furthermore, orchestrating this web relies on advanced AI decision aids, such as DARPA's ACK marketplace and ASTARTE deconfliction algorithms, to pair assets and route munitions at speeds far exceeding human cognitive limits. Yet, the pursuit of CJADC2 and the kill web is fraught with vulnerabilities. The DoD must combat the bureaucratic inertia and disjointed classification policies highlighted by the GAO, ensuring that the services do not inadvertently build a new generation of siloed, incompatible systems. Strategic leaders must remain vigilant against the "Ontology Trap," ensuring that the military retains sovereign control over its logic architecture and prioritizes distributed, edge-capable AI over fragile, centralized cloud platforms. Finally, as the speed of combat necessitates the delegation of lethal authority to algorithms, the military must ruthlessly secure its software supply chains while rigorously preserving the ethical foundations of human command. Ultimately, victory in the future battlespace will belong to the force that can seamlessly weave its disparate platforms into a unified, secure, and infinitely adaptable web.

Works cited

1. Accelerating the Air Force's Ability to Adapt and Win, https://www.airandspaceforces.com/article/accelerating-the-air-forces-ability-to-adapt-and-win/

2. (PDF) Offensive Cyber and Information Warfare Strategies Targeting People's Republic of China Military Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Systems: A Qualitative Analysis \- ResearchGate, https://www.researchgate.net/publication/403161305\_Offensive\_Cyber\_and\_Information\_Warfare\_Strategies\_Targeting\_People's\_Republic\_of\_China\_Military\_Command\_Control\_Communications\_Computers\_Intelligence\_Surveillance\_and\_Reconnaissance\_C4ISR\_Systems\_A\_Q

3. Bad Idea: All Sensors, All Shooters, All the Time – a Joint All-Domain Command and Control System That Prioritizes Centralization | Defense360, https://defense360.csis.org/bad-idea-all-sensors-all-shooters-all-the-time-a-joint-all-domain-command-and-control-system-that-prioritizes-centralization/

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

5. Sociotechnical Imaginaries, the Future and the Third Offset Strategy, https://purehost.bath.ac.uk/ws/portalfiles/portal/289770922/266113415\_Redacted.pdf

6. Mosaic Warfare: Decision-Centric Ops | PDF | Computer Network | Interoperability \- Scribd, https://www.scribd.com/presentation/531917129/Hudson-Mosaic-Summary-Brief-090121-v2

7. Chapter 1 The Emergence of Decision-Centric Warfare, https://www.nids.mod.go.jp/event/proceedings/symposium/pdf/2021/e\_01.pdf

8. OFFSET-X EVOLVED \- Special Competitive Studies Project (SCSP), https://www.scsp.ai/wp-content/uploads/2025/09/Offset-X-Evolved.pdf

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

10. Open Architecture Field Guide | Spectral Autonomy, https://spectralautonomy.com/field-guides/open-architecture

11. Sensor Open Systems Architecture (SOSA) | Curtiss-Wright Defense Solutions, https://defense-solutions.curtisswright.com/capabilities/open-architectures/mosa/sensor-open-systems-architecture

12. PROJECT MAVEN | The Architecture of Algorithmic Warfare | by Mohamed Salah \- Medium, https://medium.com/@m.salah2405/project-maven-the-architecture-of-algorithmic-warfare-3ff147e7b520

13. naval postgraduate school \- DTIC, https://apps.dtic.mil/sti/trecms/pdf/AD1224686.pdf

14. The Silence of the Screen. When Diplomacy Fails, the Network Dies… | by Dinusha Liyanage | Medium, https://medium.com/@xdinusha.liyanage/the-silence-of-the-screen-651a10e0763c

15. JADC2 Explained: How the US Military's Joint Command Network Works \- StrikeOrbit, https://strikeorbit.com/jadc2-explained-us-military-joint-command-network/

16. Final Report, https://19949847.fs1.hubspotusercontent-na1.net/hubfs/19949847/NUARI\_August2022/Pdf/nscai\_full\_report\_digital.04d6b124173c-AI.pdf

17. Autonomous Horizons: The Way Forward \- Air University, https://www.airuniversity.af.edu/Portals/10/AUPress/Books/b\_0155\_zacharias\_autonomous\_horizons.pdf

18. Implementing Decision-Centric Warfare: Elevating Command and Control to Gain an Optionality Advantage \- Amazon S3, https://s3.amazonaws.com/media.hudson.org/Clark%20Patt%20Walton\_Implementing%20Decision-Centric%20Warfare%20-%20Elevating%20Command%20and%20Control%20to%20Gain%20an%20Optionality%20Advantage.pdf

19. Closing the Sensor-to-Shooter Gap, One Dynamis Serial at a Time \- DVIDS, https://www.dvidshub.net/news/561374/closing-sensor-shooter-gap-one-dynamis-serial-time

20. The Tactical C2 Imperative: Building a Resilient, Mobile Command and Control Grid \- Mitchell Institute for Aerospace Studies, https://www.mitchellaerospacepower.org/app/uploads/2026/05/MI\_Forum\_59-Tactical-C2-Imperative-FINAL.pdf

21. (PDF) Multi-Domain Operations versus the Mosaic Warfare. Future Conflicts' Dillema Between Multi-Domain Operations and teh Mosaic Warfare \- ResearchGate, https://www.researchgate.net/publication/353259982\_Multi-Domain\_Operations\_versus\_the\_Mosaic\_Warfare\_Future\_Conflicts'\_Dillema\_Between\_Multi-Domain\_Operations\_and\_teh\_Mosaic\_Warfare

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

23. Developing the Human Machine Teaming (HMT) Ecosystem \- Amazon S3, https://s3.amazonaws.com/amz.xcdsystem.com/44ECEE4F-033C-295C-BAE73278B7F9CA1D\_abstract\_File17275/FinalPaper\_23233\_1110093203.pdf

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

25. FOOKES.RO BERT.B.JR.11 73725562 \- DAF Modernization Process Model, https://www.afacpo.com/AQDocs/AFMC\_MOSA.pdf

26. SOSA Backplanes for Defense & Military Applications, https://www.defenseadvancement.com/suppliers/sosa-backplanes/

27. OGC API \- Connected Systems Standard v1.0 Reviewers Guide, https://docs.ogc.org/guides/23-053r1.pdf

28. VPX Enclosures & Backplanes | Dawn VME Products | SOSA-Aligned Defense Solutions, https://newtecreps.com/vpx/

29. Modular Open Systems Approach \- MOSA \- Curtiss-Wright Defense Solutions, https://defense-solutions.curtisswright.com/system/files/2023-10/DSAll\_Infographic\_What-is-MOSA\_0.pdf

30. Supporting Command and Control for Land Forces on a Data-Rich Battlefield | RUSI, https://static.rusi.org/Supporting-command-and-control-for-land-forces-on-a-data-rich-battlefield.pdf

31. THE PHYSICS OF FAILURE \- Fakesoap, https://fakesoap.com/the-physics-of-failure/

32. Video Capture Boards | GPGPU Cards & Encoders | Graphics Processing \- Unmanned Systems Technology, https://www.unmannedsystemstechnology.com/company/eizo-rugged-solutions/

33. DEPARTMENT OF THE NAVY (DON) 19.2 Small Business Innovation Research (SBIR) Proposal Submission Instructions, https://www.navysbir.com/docs/Navy-19\_2\_SBIR-Topics-5-2-19.pdf

34. The Washington Headquarters Services, Acquisition Directorate on behalf of the Department of Defense releases the FY 2018 Rapi \- Webflow, https://uploads-ssl.webflow.com/5552187c43c8fafa28fd470c/5aab278dd82cc73d82bef435\_Funding%20Announcement.pdf

35. COMBINED ARMS WARFARE-NEED FOR UNMANNED AERIAL SYSTEMS (UAS)? \- CENJOWS, https://cenjows.in/wp-content/uploads/2025/12/Ch-03-PR-Kumar.pdf

36. Understanding Voice+Data Link Networking | PDF | Osi Model \- Scribd, https://www.scribd.com/document/343428484/Understanding-Voice-Data-Link-Networking

37. Welcome To Your Digital Edition Of: Aerospace & Defense Technology | PDF \- Scribd, https://www.scribd.com/document/565692401/ADT0222

38. Open Mission Systems Compliance Overview | PDF \- Scribd, https://www.scribd.com/document/648232726/Open-Mission-Systems-OMS-in-a-Nutshell

39. Universal Command and Control Interface (UCI) \- VDL \- Air Force, https://www.vdl.afrl.af.mil/programs/oam/uci.php

40. NEWLY MODERNIZED FOR CJADC2 \- Ultra Intelligence & Communications, https://www.ultra-ic.com/media/akrfaicl/adsi-datasheet-11sep25.pdf

41. WO2024263531A1 \- Systems, methods, and storage media for controlling and simulating spacecraft maneuvers \- Google Patents, https://patents.google.com/patent/WO2024263531A1/en

42. CHIPS Articles: Creating Cross-Domain Kill Webs in Real Time, https://www.doncio.navy.mil/CHIPS/ArticleDetails.aspx?ID=13872

43. A weapon system 'raises its hand' if available under DARPA program \- C4ISRNet, https://www.c4isrnet.com/c2-comms/2020/06/16/a-weapon-system-raises-its-hand-if-available-under-darpa-program/

44. DARPA Programs Overview and Goals | PDF | Artificial Intelligence \- Scribd, https://www.scribd.com/document/640986654/Untitled

45. ASTARTE program demonstrates revolutionary automated flightpath-planning software, https://alert5.com/2023/02/28/astarte-program-demonstrates-revolutionary-automated-flightpath-planning-software/

46. DARPA, Services Demonstrate Battlefield Airspace Deconfliction Software, https://www.darpa.mil/news/2023/battlefield-airspace-deconfliction-software

47. DARPA looks to AI, algorithms to de-conflict airspace \- Airforce Technology, https://www.airforce-technology.com/features/darpa-looks-to-ai-algorithms-to-de-conflict-airspace/

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

49. Quantum Optimization for CJADC2: Enhancing Multi-Domain Command and Control, https://www.davidson-tech.com/quantum-optimization-for-cjadc2-enhancing-multi-domain-command-and-control/

50. Project Dynamis \- Marines.mil, https://www.marines.mil/Project-Dynamis/

51. JUST IN: Marine Corps Gets Serious About CJADC2 with 'Project Dynamis', https://www.nationaldefensemagazine.org/articles/2025/9/23/marine-corps-gets-serious-about-cjadc2-with-project-dynamis

52. Project Dynamis Is Rewriting How Marines Fight and Share Data | AFCEA International, https://www.afcea.org/signal-media/project-dynamis-rewriting-how-marines-fight-and-share-data

53. Defining Autonomy, https://csis-website-prod.s3.amazonaws.com/s3fs-public/2026-06/260610\_Bondar\_Defining\_Autonomy.pdf?VersionId=GemYFaNtnGfELgVl\_nXIxg.bGKl2qCro

54. Defining Autonomy: Why Software, Not Drones, Will Decide the Next War \- CSIS, https://www.csis.org/analysis/defining-autonomy-why-software-not-drones-will-decide-next-war

55. Full article: The rise of the tech oligarchy and its military entanglements: a platform approach, https://www.tandfonline.com/doi/full/10.1080/09505431.2026.2666079

56. With Foundations Laid, Pentagon Building CJADC2's Data Backbone, https://www.nationaldefensemagazine.org/articles/2024/10/4/with-foundations-laid-pentagon-building-cjadc2s-data-backbone

57. Algorithmic Tradecraft: How AI and Machine Learning Are Reshaping the Intelligence Community \- Medium, https://medium.com/@brian-curry-research/algorithmic-tradecraft-how-ai-and-machine-learning-are-reshaping-the-intelligence-community-af88363af9d3

58. Maven Smart System: Innovating for the Alliance \- Palantir Blog, https://blog.palantir.com/maven-smart-system-innovating-for-the-alliance-5ebc31709eea

59. Palantir Technologies Inc. (PLTR) \- Unit Economics, https://uniteconomics.com/wp-content/uploads/2024/10/Palantir-Buy-Initiation.pdf

60. GAO Pushes DoD to Create Framework for CJADC2 Investments \- MeriTalk, https://www.meritalk.com/articles/gao-pushes-dod-to-create-framework-for-cjadc2-investments/

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

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

63. Decision Dominance at Risk: The Cross-Domain Assumption NGC2 Cannot Afford to Get Wrong \- Line of Departure, https://www.lineofdeparture.army.mil/Journals/Warrant-Officer-Journal/Archive/June-2026/Decision-Dominance/

64. Defense Dept. Still Lacks Unified CJADC2 Framework, GAO Finds, https://www.nationaldefensemagazine.org/articles/2025/4/8/defense-dept-still-lacks-unified-cjadc2-framework-gao-finds

65. cybersecurity \- Ship software without vulnerabilities., https://blog.meterian.com/tag/cybersecurity/

66. New npm Supply Chain Attack Identified: Second Wave of Shai Hulud | eSentire, https://www.esentire.com/security-advisories/new-npm-supply-chain-attack-identified-second-wave-of-shai-hulud

67. Security | UNMITIGATED RISK, https://unmitigatedrisk.com/?cat=3

68. Unfair Fights | \- pwkinternational.com, https://pwkinternational.com/2025/11/22/unfair-fights/

69. By Algorithm or Order: Integrating Lethal Autonomous Weapon Systems into Targeting, https://www.armyupress.army.mil/Journals/Military-Review/Online-Exclusive/2026-OLE/Algorithm-or-Order/

70. Killer bots instead of killer robots: Updates to DoD Directive 3000.09 may create legal implications \- The Cyber Defense Review, https://cyberdefensereview.army.mil/Portals/6/Documents/2023\_Summer/Erickson\_CDR%20V8N2%20Summer%202023.pdf?ver=bIGK4\_BcR8UvUwRAz69JUw%3D%3D

71. M W J \- Modern War Institute \-, https://mwi.westpoint.edu/wp-content/uploads/2026/03/Modern-War-Journal-MWJ-second-edition-final-draft-as-of-12MAR26-pdf.pdf