Architecting the Kill Web: A Modular Open Systems and Software Acquisition Blueprint

The institutional, legal, and technical requirements necessary to build, sustain, and continuously evolve cross-platform kill web software represent the most complex acquisition challenge facing the modern defense apparatus. The historical paradigm of purchasing monolithic platforms is entirely unsuited for a continuously evolving system-of-systems. This structural reality demands a fundamental shift in how technology is bought, tested, and owned. To operationalize this shift, this report establishes a comprehensive policy, architecture, and lifecycle blueprint, utilizing a localized research framework centered on the defense innovation nexus near Cicero, Illinois. This geographic hub provides a unique concentration of government simulation facilities, traditional prime contractors, and agile commercial vendors to empirically investigate these acquisition models.

The Acquisition Problem Statement and Systemic Friction

The traditional defense acquisition system is fundamentally optimized to procure standalone, hardware-defined platforms, such as specific fighter airframes or naval vessels, delivered as finished, static products. This apparatus struggles profoundly to acquire, test, and sustain software-defined kill webs. These dynamic, cross-platform networks require sensors, effectors, and command nodes to be entirely decoupled and constantly evolving. The friction between legacy acquisition frameworks and modern algorithmic warfare manifests across multiple operational dimensions.
The initial challenge resides in cross-platform mission outcomes and the structural siloing of Program Executive Offices. Traditional funding pathways are rigidly siloed by specific platforms, meaning no single program manager owns the end-to-end kill web mission thread. This structural reality leads directly to a severe lack of funding for the connective network infrastructure required to share data across domains. Concurrently, prime contractors have historically utilized proprietary data models and shared interfaces to guarantee vendor lock-in for long-term sustainment contracts. Without rigidly enforced open standards, cross-vendor integration requires the acquisition of expensive, bespoke translation middleware.
The traditional acquisition milestones, specifically Milestone B and C, operate under the assumption that software is a finished product at the time of fielding. However, kill webs require continuous integration and continuous delivery pipelines, utilizing modern DevSecOps practices that clash violently with static color-of-money funding constraints. While the Department of Defense Instruction 5000.87 established the Software Acquisition Pathway to enable iterative delivery, it requires programs to deploy a Minimum Viable Capability Release to an operational environment within one year of initial funding1. Calibrated models of past defense software development indicate that an initial release is unlikely to exceed twenty-eight thousand equivalent source lines of code if forced into a twelve-month window, creating immense pressure on complex embedded systems1.
Testing and certification present another systemic bottleneck. Operational testing is traditionally bounded by the physical platform itself. Certifying a software update that simultaneously impacts multiple distributed platforms across the joint force routinely overwhelms traditional operational test agencies. Furthermore, without securing unlimited or Government Purpose Rights to the modular interfaces, the government cannot easily replace underperforming vendors or authorize third-party modernization, a requirement explicitly codified in 10 U.S.C. 44014. Finally, the traditional Risk Management Framework requires authorizations that take months or years to approve, effectively neutralizing the ability to push the daily or weekly software updates necessary to counter adaptive cyber adversaries7.

Layered Reference Acquisition Model

To successfully break vendor lock-in, the acquisition strategy must physically and logically decouple hardware from software, and further separate underlying infrastructure from rapid mission applications. The following table outlines the required architectural decomposition and the distinct acquisition strategy mandated for each layer.

Stable-Versus-Rapidly-Changing Component Decomposition

A kill web cannot update its user interface or targeting algorithms at the same speed it updates its flight-control software. The architecture must account for vastly different update cadences to maintain physical safety while enabling algorithmic superiority.
The safety-critical layer represents the stable foundation of the system, encompassing flight controls, firing circuits, nuclear surety mechanisms, and baseline navigation. This layer is characterized by the need for exceptionally high determinism and strict adherence to real-time operating system safety requirements, such as DO-178C standards9. Because human life and platform survivability depend on these systems, the update cadence is measured in months to years, relying on traditional, highly rigorous test and certification regimens.
Conversely, the mission-effectiveness layer must change rapidly. This layer includes artificial intelligence object recognition models, electronic warfare threat libraries, dynamic routing algorithms, and tactical user interfaces. These components must be containerized, stateless, and strictly decoupled from the safety-critical hardware via secure hypervisors or rigid API gateways. The update cadence for mission-effectiveness applications is measured in hours to weeks. Because they cannot physically crash the aircraft or detonate a weapon prematurely due to the hypervisor boundary, their security and operational viability are validated via automated continuous integration pipelines and continuous authorization models7.

Data-Rights and Interface-Rights Framework

The transition to a Modular Open Systems Approach generates intense friction regarding intellectual property. The government does not necessarily need to own every line of proprietary source code, but it is a statutory imperative that it owns or licenses the interfaces to enable true modularity. The Defense Federal Acquisition Regulation Supplement Case 2021-D005 attempts to codify these boundaries, though it faces resistance from the defense industrial base regarding commercial market practices11.
To enforce this architecture, contracting officers must execute a rigorous interface rights strategy. Interface Control Documents must be delivered with Unlimited Rights or highly permissive Government Purpose Rights, as this is mandatory for establishing modular boundaries13. The government must secure the legal right to share API specifications with third-party competitors to stimulate innovation. The overarching system must be architected so that proprietary commercial software, which is delivered with Restricted Rights, is completely isolated behind these open, government-owned interfaces14.
Furthermore, the government must explicitly claim ownership over the telemetry and training data generated by the operational system, as this data is the foundational fuel for training future artificial intelligence models. Finally, the vendor must be contractually required to provide a comprehensive, machine-readable Software Bill of Materials for all delivered software, specifically mapping all open-source dependencies and identifying potential supply chain vulnerabilities.

Contract and Procurement Options Matrix

The decoupled nature of the kill web dictates that different layers of the architecture require fundamentally different contracting vehicles to optimize speed, cost, and vendor participation.

Vendor-Independence and Governance Strategy

Securing vendor independence requires strict adherence to statutory mandates and aggressive interface governance. The government, rather than a designated prime contractor, must author, maintain, and own the Government Reference Architecture. Allowing a prime contractor to author the reference architecture historically results in subtle proprietary extensions being embedded into the design, re-establishing vendor lock-in.
Furthermore, the acquisition strategy must decouple the system integrator from the component developer. The corporation tasked with integrating the kill web should ideally be prohibited from developing the proprietary sensors or effectors utilized within that web. This separation removes the inherent conflict of interest where an integrator prioritizes its own sub-optimal hardware over a competitor’s superior technology. Mandatory conformance to open standards, specifically the Sensor Open Systems Architecture for hardware and the Future Airborne Capability Environment and Open Mission Systems for software, must serve as a primary evaluation factor during source selection15.

Conformance-Test Strategy

A system is not truly open simply because a vendor claims adherence to a standard. Historical acquisition data indicates that vendors routinely add proprietary extensions to open standards, effectively rendering the system closed to third-party developers. To combat this, the acquisition framework requires a strict conformance-test strategy utilizing automated API testing.
Vendors must be required to submit their software to a persistent, government-owned digital sandbox. This sandbox executes automated test scripts to ensure the software ingests and outputs data exactly according to the Open Mission Systems and Universal Command and Control Interface standards16. The conformance strategy must maintain a zero-tolerance policy for undocumented extensions, automatically rejecting any software module that relies on proprietary data fields to achieve its advertised functionality.

Continuous-Authorization Evidence Model

To operationalize the rapid deployment of mission applications, the traditional Risk Management Framework must shift from a manual, document-based compliance exercise to a continuous, pipeline-based evidence generation model. The Department of Defense has initiated this shift through the Continuous Authorization to Operate framework, which treats DevSecOps maturity as the primary security metric7.
Under this model, the security boundary is drawn around the software factory and the deployment pipeline itself, rather than the individual software release. All applications must run within Department of Defense-approved hardened containers, utilizing repositories such as Iron Bank to ensure base image integrity. The Continuous Authorization to Operate relies on three core pillars: continuous monitoring of risk management controls, active cyber defense to respond to real-time threats, and a secure software supply chain7. By automating security evidence generation, including static and dynamic code analysis, vulnerability scanning, and the generation of the Software Bill of Materials, the pipeline outputs security artifacts as a native byproduct of the build process, enabling software to be deployed to the tactical edge in hours rather than years.

Joint Mission-Thread Test Framework and the Illinois Research Nexus

The most significant operational failure in modern acquisition occurs when individual components pass their isolated tests, but the integrated kill web fails due to network latency, interface incompatibility, or data routing errors. To resolve this, the acquisition blueprint mandates a “shift-left” approach to mission testing, utilizing a persistent Digital Engineering environment where software from disparate vendors is virtually integrated before physical hardware is manufactured.
To investigate and validate this framework, this research plan leverages the defense innovation nexus located near Cicero and the greater Chicago, Illinois area. Argonne National Laboratory, located in Lemont, provides unparalleled high-performance computing and cybersecurity simulation capabilities17. Argonne’s researchers, who routinely simulate catastrophic cyberattacks on critical infrastructure, will host the virtual Live-Virtual-Constructive mission thread environment18.
Within this localized testbed, the research will simulate the integration of hardware and software from two distinct corporate profiles located in nearby Rolling Meadows. Northrop Grumman represents the traditional prime contractor, manufacturing highly complex, safety-critical legacy systems such as the AN/APR-39E(V)2 digital radar warning receiver9. Epiq Solutions represents the agile, commercial vendor, producing low-SWaP software-defined radios like the Sidekiq VPX400, which actively utilizes the Sensor Open Systems Architecture and the Modular Open Radio Frequency Architecture20.
By injecting virtual targets into a live network connecting an Epiq RF sensor to a simulated Northrop Grumman effector inside the Argonne supercomputing environment, the research will empirically test operational acceptance. Accountability for thread failure within this Live-Virtual-Constructive environment must be arbitrated by a Joint Systems Engineering node, ensuring that individual platform program managers cannot deflect blame for integration failures.

Governance and Accountability Map

The successful execution of a kill web requires a fundamental realignment of accountability. Traditional structures optimize for platform delivery, whereas the kill web optimizes for data routing and mission effects.
The Platform Program Executive Office must retain ownership of physical safety, airworthiness, seaworthiness, and the integration of hardware onto the chassis. Their primary mandate is ensuring the physical asset functions reliably. A newly established Software Portfolio Executive must own the digital app store, the continuous integration pipelines, and the overarching DevSecOps factory infrastructure, providing the digital roads upon which the mission applications travel.
Crucially, a Joint Interface Control Board must be empowered to own the data dictionary and the API standards. This board serves as the ultimate arbiter, resolving technical disputes when one vendor blames another for integration failures across the open architecture. Finally, the Operational Commander exercises absolute command authority, utilizing live telemetry to set the priority backlog for which specific mission threads require immediate software updates to counter emerging battlefield threats.

Transition and Rollback Plan

Given the velocity of software deployments in a kill web architecture, the transition plan must prioritize system resilience and automated recovery. The architecture mandates the use of Blue/Green deployment methodologies. The new software version, designated as Green, is fielded alongside the currently active and stable version, designated as Blue. Shadow operational traffic is routed to the Green deployment to verify functionality, memory usage, and interface compliance in real-time before active control is seamlessly switched.
If the new mission software violates predefined safety parameters, generates fatal exceptions, or crashes, the underlying secure hypervisor must instantly execute an automated rollback, reverting active control to the stable Blue baseline within milliseconds. To support this, data state preservation protocols must be strictly enforced. All database schema changes introduced by new software must be fully backward compatible, ensuring that an automated rollback does not corrupt existing mission data or target tracks.

Proposed Public KillWebs.com Acquisition Lab

To address the cultural and educational deficit within the acquisition workforce, this research plan proposes the development of a public, web-based simulation platform designated as “KillWebs.com,” hosted on Argonne National Laboratory’s unclassified infrastructure. This platform is designed specifically to educate Acquisition Professionals, Contracting Officers, and Program Managers on the counterintuitive realities of open systems procurement.
The simulation fundamentally teaches the difference between platform ownership and mission-thread value. Users are allocated a budget and must make procurement decisions. Purchasing a highly advanced standalone fighter jet yields a marginal capability increase, whereas purchasing a data-link API that successfully connects five existing legacy jets yields a massive, asymmetric capability increase. The platform also clearly delineates the difference between open interfaces and open source, demonstrating that the government does not need to open-source classified proprietary algorithms to achieve interoperability, provided they secure the interface specifications. Finally, the simulation features a module demonstrating the “component pass versus thread fail” paradigm, where users who purchase highly rated but proprietary components witness their entire mission thread collapse due to an inability to route targeting data.

Developer and Content Backlog for the Simulation Lab

The development of the KillWebs.com simulation platform is structured around four primary software epics, designed to gamify the acquisition process and provide experiential learning.
The first epic encompasses the API Sandbox. This interactive module visually demonstrates how data flows between a sensor and a shooter utilizing a mock Open Mission Systems message structure. Users must manually map data fields to successfully execute a simulated strike, teaching the rigid necessity of data standards.
The second epic features the Data Rights Negotiator. This branching narrative game places the user in the role of a Contracting Officer negotiating Defense Federal Acquisition Regulation Supplement clauses with a fictional prime contractor13. The user must successfully secure Government Purpose Rights for Interface Implementation Data without violating the vendor’s commercial intellectual property protections, simulating the complex negotiations mandated by DFARS Case 2021-D00514.
The third epic is the cATO Simulator. This visual pipeline demonstrates how a developer’s code commit triggers a cascade of automated static tests, dynamic security scans, and software bill of materials generation. Users must configure the pipeline to satisfy the three pillars of continuous authorization before the software is permitted to deploy to the simulated tactical edge7.
The final epic is the Vendor Swap puzzle. Users are presented with two systems: a tightly coupled proprietary system and a loosely coupled modular system based on the Sensor Open Systems Architecture. Users must attempt to swap out an obsolete processing module in both systems, physically demonstrating the massive schedule and cost reductions enabled by standardized backplane interfaces like VITA 67.322.

Procurement Scenarios Wargaming

To further stress-test the acquisition workforce, the research plan includes six detailed fictional procurement scenarios that map directly to common operational failures and successes.
The first scenario explores the “Proprietary Trap.” A program manager purchases a highly capable, autonomous drone but fails to secure the data rights to the internal interfaces. Years later, when the operational environment demands a new optical sensor, the original vendor leverages their intellectual property monopoly to charge exorbitant, extortionate integration fees. The lesson reinforces the absolute necessity of securing interface rights at Milestone A.
The second scenario demonstrates a “MOSA Success.” A program manager strictly mandates hardware aligned with the Sensor Open Systems Architecture. Two years into deployment, a critical processing card becomes obsolete. Because the system utilizes standard VITA interfaces, the program manager successfully swaps the obsolete card for a cheaper, highly advanced processor from an agile commercial competitor in a matter of hours, rather than months22.
The third scenario highlights the “RMF Bottleneck.” An artificial intelligence team develops a critical update to an electronic warfare threat library that can neutralize a new adversary radar. However, because the program relies on traditional compliance documentation, it takes nine months to secure an Authority to Operate, by which time the adversary has already changed their radar frequencies. The scenario proves the operational necessity of software factories and continuous authorization.
The fourth scenario explores the “Extension Exploit.” A vendor delivers a system that successfully passes basic Open Mission Systems compliance. However, the vendor secretly utilizes proprietary data extensions for key targeting features. When the government attempts to integrate a third-party effector, the system fails to communicate. This scenario underscores the need for strict, automated conformance testing that rejects undocumented extensions.
The fifth scenario addresses the “Color of Money Crisis.” A program manager attempts to utilize traditional Operations and Maintenance funds to sustain a continuous software delivery pipeline, ultimately triggering severe Anti-Deficiency Act violations. The scenario educates the workforce on utilizing the Software Acquisition Pathway and leveraging specific software appropriations, such as the BA08 pilot program, to fund iterative development25.
The final scenario illustrates a “Coalition Breakdown.” United States platforms share targeting data flawlessly utilizing an open architecture. However, allied coalition forces cannot ingest the data due to hardcoded, US-only cryptographic standards embedded deeply in the application layer. The scenario teaches the necessity of architecting for zero-trust and Attribute-Based Access Control from day one, ensuring data can be filtered and shared without triggering export control violations27.

Expected Outcomes, Tradeoffs, and Strategic Unknowns

The implementation of this modular, software-defined acquisition blueprint is expected to yield transformative outcomes, but it requires accepting significant strategic tradeoffs. The primary outcome is a drastic reduction in the time required to field new capabilities, accelerating timelines from multi-year cycles to days or hours. However, this velocity requires the tradeoff of drastically increased upfront systems engineering costs to meticulously define the reference architectures and data dictionaries before any hardware is built.
A secondary outcome is the complete elimination of vendor lock-in, enabling a diverse industrial base of agile commercial vendors to compete on a level playing field. The corresponding tradeoff is that traditional prime contractors will fiercely resist this erosion of their profit margins, arguing that open systems introduce unacceptable integration risks, lower overall system reliability, and jeopardize their intellectual property investments11. Furthermore, while continuous software delivery massively improves cybersecurity through rapid patching and active defense, it generates intense cultural friction between traditional hardware-centric test and evaluation communities and agile software developers8.
As the research plan executes within the Illinois defense nexus, it must confront several critical unknowns that require high-level legal and congressional adjudication. The first involves liability within the kill web, governed broadly by Department of Defense Directive 3000.09 regarding autonomy in weapons systems29. If a third-party artificial intelligence module directs a prime contractor’s kinetic weapon to strike an invalid target due to a sensor anomaly, the legal framework for assigning liability across a multi-vendor, continuous delivery ecosystem remains dangerously unresolved31.
A second critical unknown is coalition intellectual property sharing. The research must determine how the United States can share detailed Interface Control Documents and modular specifications with allied nations without violating the International Traffic in Arms Regulations or exposing commercial intellectual property32. While initiatives like the AUKUS exemptions provide a potential framework, broader coalition data sharing remains severely hampered by legacy export control regimes32.
Finally, the department must resolve the challenge of funding the connective tissue. Because congressional appropriations are tied to physical platforms, determining who pays for the joint network bandwidth, the cross-domain data lakes, and the foundational API infrastructure that benefits the entire joint force but belongs to no single platform remains a paramount legislative hurdle. This research blueprint provides the empirical foundation necessary to answer these questions and successfully architect the decentralized, software-defined kill web of the future.

Works cited

1. WHEN IS IT FEASIBLE (OR DESIRABLE) TO USE THE SOFTWARE ACQUISITION PATHWAY? (Conference Paper), https://www.ida.org/assets/2026/06/18010355/D-33047.pdf
2. Transitioning the DoD’s Software Acquisition Pathway to Programs, https://www.sei.cmu.edu/annual-reviews/2021-year-in-review/transitioning-the-dods-software-acquisition-pathway-to-programs/
3. New defense policy released for Software Acquisition Pathway - DoDI 5000.87, https://acquisitiontalk.com/2020/10/new-defense-policy-released-for-software-acquisition-pathway-dodi-5000-87/
4. Modular Open Systems Approach (MOSA) - Defense Standardization Program, https://www.dsp.dla.mil/Programs/MOSA/
5. 10 USC 4401: Requirement for modular open system approach in major defense acquisition programs; definitions, https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title10-section4401\&num=0\&edition=prelim
6. 10 USC 4401 - Requirement for modular open system approach in major defense acquisition programs - GovRegs, https://www.govregs.com/uscode/expand/title10_subtitleA_partV_subpartF_chapter327_subchapterI_section4401
7. Unpacking the DoD Continuous Authorization to Operate (cATO) Evaluation Criteria - Part I, https://breakpoint-labs.com/unpacking-the-dod-continuous-authorization-to-operate-cato-evaluation-criteria-part-i-intro-to-cato/
8. Navigating Continuous Authority To Operate (cATO): A Guide - Anchore Enterprise, https://anchore.com/blog/continuous-authority-to-operate-the-realities-and-the-myths-2/
9. Northrop Grumman - Military Embedded Systems, https://militaryembedded.com/company/northrop-grumman
10. Software Acquisition Pathway Integration with Risk Management Framework, https://dodcio.defense.gov/Portals/0/Documents/Library/SWAPathwayIntegration-RMF.PDF
11. POLICY POINTS: The Balance of Protecting IP and Data Rights, https://www.nationaldefensemagazine.org/articles/2024/10/4/policy-points-the-balance-of-protecting-ip-and-data-rights
12. Defense Federal Acquisition Regulation Supplement: Modular Open Systems Approaches (DFARS Case 2021-D005), https://www.federalregister.gov/documents/2023/11/17/2023-25407/defense-federal-acquisition-regulation-supplement-modular-open-systems-approaches-dfars-case
13. NDIA Comments on Defense Federal Acquisition Regulation Supplement Modular Open Systems Approaches (DFARS Case 2021-D005), https://www.ndia.org/-/media/sites/ndia/policy/regulatory-submission-tracker/2024/ndia-comments—dfars-case-2021-d005—mosa—final.pdf?download=1
14. What Defense Innovators Need to Know About Defense Dept.’s Changes to IP Rights, https://www.fenwick.com/insights/publications/what-defense-innovators-need-to-know-about-defense-dept-s-changes-to-ip-rights
15. Modular Open Systems Approach – DoW Research & Engineering, OUSW(R\&E), https://www.cto.mil/sea/mosa/
16. Open Architecture Management (OAM) - VDL - Air Force, https://www.vdl.afrl.af.mil/programs/oam/
17. Best Cybersecurity Degree Programs in Illinois, 2026 Rankings - Hakia, https://hakia.com/degrees/cybersecurity/illinois/
18. The Doomsday Squad - Chicago Magazine, https://www.chicagomag.com/chicago-magazine/february-2017/the-doomsday-squad/
19. Digital radar warning receiver for U.S. Army begins production - Military Embedded Systems, https://militaryembedded.com/radar-ew/sensors/digital-radar-warning-receiver-for-us-army-begins-production
20. Epiq Solutions, https://epiqsolutions.com/
21. An Introduction to SOSA | Epiq Solutions, https://blog.epiqsolutions.com/an-introduction-to-sosa-1
22. SOSA’s rubber is meeting the road in rapid system development, https://militaryembedded.com/radar-ew/rf-and-microwave/sosas-rubber-is-meeting-the-road-in-rapid-system-development
23. Federal Register/Vol. 88, No. 221/Friday, November 17, 2023/Proposed Rules - GovInfo, https://www.govinfo.gov/content/pkg/FR-2023-11-17/pdf/2023-25406.pdf
24. RF I/O for SOSA-Aligned Systems, https://blog.epiqsolutions.com/rf-i/o-for-sosa-aligned-systems
25. Draft memo reveals potentially sweeping Pentagon acquisition reforms - Breaking Defense : r/fednews - Reddit, https://www.reddit.com/r/fednews/comments/1oob4lb/draft_memo_reveals_potentially_sweeping_pentagon/
26. Proceedings, https://www.dair.nps.edu/bitstream/123456789/5505/1/SYM-AM-26-068.pdf
27. Overcoming the Challenges of Coalition Data Sharing - Owl Cyber Defense, https://owlcyberdefense.com/wp-content/uploads/2021/01/20-OWL-0421-Coalition-Data-Sharing-White-Paper.pdf
28. Avoid a Governance Apocalypse with Continuous Compliance - Tanzu - VMware Blogs, https://blogs.vmware.com/tanzu/avoid-a-governance-apocalypse-with-continuous-compliance/
29. Artificial Intelligence in Defense Contracting- What Contractors Need to Know Now - The National Law Review, https://natlawreview.com/article/artificial-intelligence-defense-contracting-what-contractors-need-know-now
30. AI Priorities Focus on Defense + Intelligence Agencies - Fluet Law, https://fluet.law/ai-priorities-focus-on-defense-intelligence-agencies/
31. AI-Enabled Autonomous Weapons and Human Control Part II: Human Control and Military Commanders - U.S. Naval War College Digital Commons, https://digital-commons.usnwc.edu/cgi/viewcontent.cgi?article=3116\&context=ils
32. defense innovation board - optimizing innovation cooperation with allies and partners, https://stib.cto.mil/wp-content/uploads/2026/01/2024-1_20240710-DIB-AlliesandPartnersStudy_DOD-CLEARED_FINAL_1.pdf
33. A High-Tech Alliance: Challenges and Opportunities for U.S.-Japan Science and Technology Collaboration | Carnegie Endowment for International Peace, https://carnegieendowment.org/research/2021/07/a-high-tech-alliance-challenges-and-opportunities-for-us-japan-science-and-technology-collaboration
34. International Cooperation to Expand the Industrial Base and Enable Burden Sharing - MITRE, https://www.mitre.org/sites/default/files/2026-07/PR-26-1175-International-Cooperation-Expand-Industrial-Base-Enable-Burden-Sharing.pdf