From Kill Chain to Kill Web: Strategic Rationale, Technical Architecture, and DARPA’s ACK Program

From Kill Chain to Kill Web: Strategic Rationale, Technical Architecture, and DARPA’s ACK Program

Executive summary

A traditional kill chain organizes an engagement as a largely predetermined sequence: find a target, fix its location, track it, select a response, engage, and assess the result. That sequence remains indispensable because every actual use of force still requires sensing, identification, authorization, action, and assessment. The transition to a kill web therefore does not eliminate kill chains. It creates a networked decision and coordination layer capable of assembling, comparing, executing, and—when conditions change—reassembling many possible kill chains from distributed sensors, command-and-control nodes, communications paths, support services, and effectors. This report uses that functional definition because no single public DoD document establishes one universally binding technical definition of “kill web.” citeturn7search1turn18view0turn19view6

For senior leaders, the simplest analogy is the difference between a fixed railway line and a resilient transportation network. A railway line is highly efficient while every station and track segment works, but one destroyed bridge may stop the entire route. A transportation network can reroute passengers through other roads, airports, carriers, and transfer points. Similarly, a kill web attempts to preserve mission outcomes when a particular sensor, data link, command post, weapon, or supporting organization becomes unavailable. DARPA described this advantage as the ability to make rapid substitutions, expose latent capacity, balance tasking across domains, and pair the right sensor and weapon for a particular operational problem. citeturn18view0

The strategic value comes from optionality. Instead of asking whether a specific preplanned sensor-to-shooter chain is intact, a commander asks which combinations of available capabilities can still produce the desired effect, under current authorities, risk, timing, capacity, and quality constraints. This can increase operational tempo, impose a more complex targeting problem on an adversary, reduce dependence on a small number of exquisite platforms, and support distributed decision-making when higher headquarters or long-haul communications are disrupted. DoD’s JADC2 strategy similarly calls for the ability to “sense, make sense, and act” across domains, using federated data fabrics, automation, common standards, and resilient infrastructure in degraded electromagnetic environments. citeturn19view1turn19view2turn19view3

The shift is not merely a networking project. A functioning kill web requires simultaneous progress in six areas: resilient communications; federated cloud and edge computing; shared data semantics and open interfaces; capability discovery and orchestration; identity-centric, zero-trust security; and organizational mechanisms that reconcile authorities, priorities, resource ownership, and rules of engagement. DoD’s own modernization documents acknowledge that current C3 environments still contain multiple data formats, non-interoperable interfaces, stovepiped flows, and incompatible data links, while GAO has repeatedly found that DoD historically prioritized individual systems over joint interoperability. citeturn22view2turn22view1

There is no public, universal DoD latency threshold for a kill web. Required performance depends on threat speed, geography, weapon dynamics, human authorization, communications media, and acceptable risk. DARPA’s public target for ACK was not a millisecond fire-control loop; it was to reduce cross-domain asset reallocation and assignment decisions to the order of minutes. Faster defensive or fire-control functions must remain at the tactical edge and use mission-specific subsecond or seconds-level budgets rather than depend on a distant cloud or enterprise marketplace. citeturn19view0

DARPA’s Adapting Cross-Domain Kill-Webs, or ACK, program addressed the decision and resource-composition portion of the problem. It treated organizations needing an effect as marketplace “consumers,” organizations offering capabilities as “suppliers,” and used bid-and-offer concepts adapted from e-commerce, sourcing, and supply-chain management. A “Virtual Liaison” abstraction allowed organizations to advertise what effect they could provide, with associated availability and constraints, without necessarily exposing sensitive sources and methods. Algorithms then compared candidate combinations and recommended a command-and-control “play” to a mission commander. citeturn18view0turn19view0

ACK was demonstrated during an Air Force Advanced Battle Management System event in 2020. In an air-defense scenario, DARPA reported that ACK evaluated thousands of options, recommended assets and a C2 play, and passed the selected play to operational applications. A separate DARPA technology, STITCHES, provided machine-to-machine integration among heterogeneous systems and supported cuing over Link 16. This distinction is important: ACK selected and orchestrated capabilities; STITCHES translated and connected fielded systems. citeturn18view1

ACK is now publicly listed as complete, and DARPA states that its technology transitioned to the military Services. Public sources do not disclose the transition recipients in detail, operational fielding status, marketplace algorithms, capstone performance data, cybersecurity architecture, or classified evaluation results. More broadly, GAO reported in 2025 that DoD had established a JADC2 reference architecture, reference design, campaign plans, and a capstone requirements document, but that further progress still depended on a more comprehensive framework for synchronizing development and investment. citeturn18view0turn19view0turn22view0

The transition from Kill Chain to Kill Web

The familiar joint-targeting formulation F2T2EA—find, fix, track, target, engage, assess—is best understood as a workflow for completing one engagement. Its linear representation helps clarify responsibilities, decision points, and required information. Its weakness is not that the individual steps are obsolete, but that an organization may bind those steps too early to particular platforms, networks, headquarters, or service-specific systems. citeturn7search1turn19view6

A kill web moves binding decisions later. Sensors publish observations and capability status; fusion services build tracks and confidence assessments; effectors and support providers advertise what they can accomplish; networks expose current reachability and quality; authorities and policies constrain which combinations are permissible; and orchestration software assembles one or more executable paths. The selected path is still a chain at the moment of execution, but it is selected from a changing graph of alternatives rather than assumed to be the only viable route. This interpretation is consistent with DARPA’s contrast between monolithic predefined chains and adaptive cross-domain kill webs, and with RAND’s characterization of nonlinear webs that bring sensors and shooters together across service, domain, and functional stovepipes. citeturn18view0turn19view6

The table is a synthesis rather than a formal doctrinal taxonomy. DARPA, DoD, and RAND sources consistently emphasize composability, cross-domain substitution, shared resources, federated information, and resilience, while also warning that distributed architectures require robust communications, new command approaches, and different acquisition and testing practices. citeturn18view0turn19view2turn19view7turn19view8

A useful graph-theoretic description is:

\[ \text{Kill Web} = (V,E,C,P,S) \]

where \(V\) represents capabilities such as sensors, fusion nodes, networks, decision authorities, effectors, and assessment services; \(E\) represents feasible information, command, and support relationships; \(C\) represents capacity, timing, quality, and dependency constraints; \(P\) represents policy, authority, security, and rules-of-engagement constraints; and \(S\) represents the current operational state. A kill chain is then a permitted path or subgraph selected from this web for a particular mission.

This distinction prevents a common misconception: a kill web is not simply “connecting every sensor to every shooter.” Full physical or logical connectivity would be costly, congested, difficult to secure, and often unnecessary. The objective is selective reachability and composability: the right data and capability must become discoverable to an authorized consumer, through an acceptable path, within the relevant mission window.

Executive-level explanation of why the shift matters

Resilience changes from protecting a route to preserving an outcome. In a chain-oriented model, an adversary can attempt to identify the critical reconnaissance platform, command node, relay, or weapon whose loss breaks the sequence. In a web-oriented model, the adversary must suppress multiple alternative sensors, communications paths, decision nodes, and effectors—or prevent them from recombining. RAND’s immune-system analogy captures both the advantage and the cost: a distributed force may remain effective after individual platforms fail, but it may require redundancy, robust communications, and more distributed command arrangements. citeturn19view8

The closest civilian analogy is the Internet. A user requests an outcome—delivery of data—not a specific sequence of routers. Routing systems select paths based on reachability and conditions, and traffic may be redirected after a failure. A military kill web applies a comparable principle at a much higher level of consequence: it routes not only data but also sensing, analysis, authority, support, and effects. Unlike the public Internet, however, military composition must obey classification rules, coalition releasability, weapon safety constraints, legal reviews, resource priorities, and commander intent.

Tempo improves because coordination can become machine-assisted rather than meeting-driven. In a traditional cross-service process, discovering which organization owns an appropriate capability, whether it is available, whether its data can be released, and who can authorize its use may involve serial voice calls and liaison activity. ACK’s Virtual Liaison concept sought to encode part of this work in machine-readable offers, requests, and constraints, allowing algorithms to compare large numbers of possible combinations before presenting choices to a commander. DARPA’s 2020 demonstration reported analysis of thousands of options in an air-defense scenario. citeturn18view0turn18view1

The advantage is not simply making the same decision faster. It is making a broader decision within the available time. A human staff may compare two or three familiar options; software may screen thousands, discard infeasible combinations, and expose several non-obvious but permissible alternatives. Human attention can then be concentrated on strategic judgment, escalation, proportionality, uncertainty, and second-order effects rather than on manually locating and reconciling data.

Distributed decision-making becomes practical when intent and constraints travel with the mission. A resilient force cannot assume continuous communication with one central command post. A kill-web architecture therefore needs to distribute mission intent, authorities, policy, resource limits, and fallback behavior to lower echelons before communications fail. Local nodes can then continue sensing, fusing, and executing within delegated boundaries, while reconnecting and synchronizing when links return. DoD’s JADC2 strategy explicitly anticipates degraded and contested electromagnetic environments and requires resilient C2 rather than uninterrupted dependence on a central enterprise service. citeturn19view1turn19view2

Distributed execution does not mean uncontrolled decentralization. It requires a clear distinction among decisions that may be automated, decisions that may be made by a delegated local commander, and decisions that must return to a specified authority. DoD policy for autonomous and semi-autonomous weapon systems requires appropriate levels of human judgment, understandable human-machine interfaces, transparent system status, realistic testing, and compliance with law and rules of engagement. ACK itself was publicly described as a decision aid that recommended plays to a commander, not as an autonomous weapon-release authority. citeturn22view3turn18view1

Resource utilization improves because capabilities can be represented by effects rather than ownership. A platform that is fully tasked in one role may still have unused sensing, processing, relay, electronic-warfare, or weapons capacity. A marketplace-like mechanism can expose that capacity and allow another organization to request it without permanently transferring ownership. DARPA called this latent capacity and argued that cross-domain sharing could balance tasking loads. citeturn18view0

The web can impose cost and uncertainty on an adversary. When the force can substitute platforms and routes, eliminating one capability may no longer produce the expected operational effect. The opponent must expend more surveillance and weapons to understand and disrupt a changing system. This advantage is conditional, however. If every nominally different path depends on the same satellite constellation, timing source, cloud region, identity provider, software library, or central broker, the apparent web may conceal a common-mode vulnerability.

The main executive caveat is that connectivity does not equal effectiveness. A kill web with poor data quality may distribute errors faster. A poorly governed marketplace may double-book scarce assets or optimize one mission at the expense of a more important one. Excessive automation may overwhelm operators with recommendations or obscure why a choice was made. RAND identified trust, explainability, training, data stewardship, and changed staffing requirements as important parts of all-domain C2 modernization, not secondary adoption issues. citeturn19view10

The executive measure of success should therefore be mission continuity under stress, not the number of connected systems. Representative metrics include the percentage of priority missions that remain executable after loss of selected nodes; time to discover and validate an alternate path; number of independent failure domains represented in each mission plan; decision quality under stale or deceptive data; and the ability of local forces to operate safely during disconnection.

Technical backbone for a functioning Kill Web

The recommended architecture is a federated hybrid cloud–edge mission mesh, not a single centralized cloud and not an unrestricted all-to-all network. Enterprise clouds should host durable catalogs, large-scale analytics, model development, historical data, global planning, and software delivery. Theater or regional edge clouds should provide operational fusion, orchestration, and replicated mission services. Platform and tactical-edge computers should perform time-critical sensing, tracking, policy enforcement, and local control even when disconnected. This pattern follows DoD’s direction toward federated data fabrics, cloud-ready systems, common standards, and resilient operations at the contested tactical edge. citeturn19view3turn19view4turn19view9

The architectural rule should be place a function at the slowest and least exposed tier that still meets its deadline. Global force optimization may tolerate minutes and belong in a theater or enterprise environment. Track correlation may require seconds and belong at a regional or tactical edge. Terminal defensive control may require milliseconds to fractions of a second and must remain local to the sensor-effector complex. A distant cloud may enrich or supervise such a loop, but it should not be a required synchronous dependency.

The end-to-end deadline should be engineered from the mission window rather than inherited from a generic network requirement:

\[ T_{\text{total}} = T_{\text{sense}}+ T_{\text{preprocess}}+ T_{\text{transport}}+ T_{\text{fusion}}+ T_{\text{decision}}+ T_{\text{authority}}+ T_{\text{tasking}}+ T_{\text{effector}} \]

\[ T_{\text{total}} < T_{\text{opportunity window}} - T_{\text{weapon/response margin}} - T_{\text{safety margin}} \]

Average latency is insufficient. Requirements should specify percentile latency, jitter, deadline-miss rate, data age, track-update interval, loss behavior, recovery time, and the maximum duration for which local nodes can operate with disconnected or stale enterprise state.

Illustrative engineering latency tiers—recommended planning values, not published DoD doctrine

The figures above are starting points for requirements analysis. They cannot be finalized without threat kinematics, sensor accuracy, weapons data, geography, communications paths, and authorization mode. For example, a target traveling 300 meters per second accumulates 300 meters of uncompensated positional age in one second; whether that is acceptable depends on tracking prediction, covariance, weapon seeker capability, and engagement geometry.

flowchart LR
    I[Commander intent<br/>desired effect, priority, time, risk] --> R[Machine-readable request]
    R --> M[Capability marketplace<br/>and federated registries]

    subgraph Suppliers
        S1[Sensor offers]
        S2[Network and relay offers]
        S3[Fusion and processing offers]
        S4[Effector offers]
        S5[Support and assessment offers]
    end

    S1 --> V[Virtual Liaisons<br/>abstract capabilities and constraints]
    S2 --> V
    S3 --> V
    S4 --> V
    S5 --> V
    V --> M

    M --> O[Time-bounded matching<br/>constraint satisfaction and ranking]
    O --> P[Policy, authority, security<br/>and rules-of-engagement gate]
    P --> C[Commander or delegated<br/>decision authority]
    C --> B[Reserve capabilities<br/>and commit selected play]

    B --> Q[Sensor cue and collection]
    Q --> E[Edge preprocessing<br/>time, location, confidence, provenance]
    E --> F[Federated data fabric<br/>track fusion and dissemination]
    F --> D[Local or theater decision service]
    D --> T[Effector tasking]
    T --> X[Effect]
    X --> A[Assessment and battle-damage<br/>or mission-effect evaluation]
    A --> M
    A --> I

    L[Loss, jamming, overload,<br/>capacity or authority change] -. status update .-> M
    L -. alternate route or substitute .-> O

This flow is a synthesis of DARPA’s public ACK descriptions and DoD’s sense–make sense–act and federated-data-fabric concepts. It is not a released ACK system diagram. citeturn18view0turn19view3

Technical requirements and implementation options

DoD’s MOSA principles are particularly important because a kill web must be designed for substitution. MOSA calls for modular, loosely coupled, highly cohesive components and widely supported consensus standards, with key interfaces identified and made available. OMS, UCI, and SOSA provide useful domain-specific building blocks, but none by itself constitutes a complete joint kill-web data model. citeturn21search4turn21search5turn21search2

The best interoperability strategy is therefore semantic convergence plus controlled mediation, not a demand that every legacy platform adopt one new wire protocol. New capabilities should publish standard data contracts and expose modular interfaces. Existing platforms should connect through governed adapters whose behavior, latency, information loss, and security properties are tested. DARPA’s ACK demonstration illustrates this separation of concerns: ACK handled option generation and orchestration, while STITCHES created the middleware needed to exchange information among heterogeneous fielded systems. citeturn18view1

Consistency should also be selective. Capability catalogs, health information, and noncritical situational data can often use eventual consistency during communications disruption. Weapon reservations, authority state, no-fire areas, positive identification status, and release commands require stronger guarantees, explicit conflict handling, or locally authoritative ownership. Trying to impose synchronous global consistency on every data item would make the web fragile under contested connectivity.

DARPA’s Adapting Cross-Domain Kill-Webs program

DARPA defined ACK’s goal as providing mission commanders a decision aid for rapidly identifying and selecting options to task and retask assets across organizational boundaries. The program covered sensors, effectors, and supporting elements in space, air, land, surface, subsurface, and cyber domains. Its central premise was that disaggregated forces could be composed into adaptive webs instead of relying exclusively on limited, monolithic, predefined chains. citeturn18view0

DARPA identified three principal problems. Commanders lacked timely visibility into capabilities, capacity, and quality of service outside their own domains. Different organizations operated under different missions and authorities, making it difficult to calculate the cost or value of diverting an asset to another organization’s request. Finally, even when multiple options existed, commanders needed a rapid method for comparing them and selecting the best option under current conditions. citeturn18view0

The public description of ACK’s Capability Marketplace supports the following logical reconstruction:

DARPA explicitly described ACK as adapting techniques from online commerce, sourcing, and supply-chain management, including bid requests and offers. The “market” was not intended to imply a literal cash auction. It was a computational mechanism for exposing supply and demand, reconciling constraints, and allocating scarce capabilities. citeturn18view0turn19view0

A capability advertisement suitable for operational use would need to contain substantially more than a platform name. A sensor offer might state the types of objects it can observe, geographic and altitude coverage, revisit interval, expected accuracy, environmental limits, collection latency, confidence, emissions profile, security classification, releasability, and current task load. An effector offer might represent the effect it can provide, operational envelope, response time, inventory, support dependencies, authority requirements, and risk. The marketplace then composes offers only when their interfaces, timing, location, and policies align.

The Virtual Liaison is the most distinctive publicly described ACK abstraction. A traditional liaison officer understands another organization’s capabilities, vocabulary, priorities, and authorities and helps staff officers negotiate support. ACK attempted to make part of that role executable as a service. DARPA also emphasized that suppliers could advertise effects without exposing the detailed sources and methods used to produce them, helping protect sensitive capabilities while permitting cross-domain use. citeturn18view0

This abstraction has an inherent engineering tension. If a supplier discloses too little, the matching engine cannot accurately judge feasibility, timing, confidence, or risk. If it discloses too much, the marketplace may expose classified capabilities, vulnerabilities, readiness, or intelligence sources. A production design therefore needs tiered disclosure: coarse information for discovery, more detailed information after authorization, and tightly controlled technical data only when required to commit and execute the mission.

ACK’s selection problem can be expressed as a constrained optimization:

\[ \max_{w \in W} U(w) \]

subject to:

\[ \begin{aligned} &\text{deadline}(w) \leq T_{\max}\\ &\text{confidence}(w) \geq C_{\min}\\ &\text{capacity}(v) \geq \text{demand}(v), \quad \forall v \in w\\ &\text{authorities}(w) = \text{valid}\\ &\text{security}(w) = \text{permitted}\\ &\text{interfaces}(w) = \text{compatible}\\ &\text{risk}(w) \leq R_{\max} \end{aligned} \]

Here, \(W\) is the candidate set of kill-web compositions and \(U(w)\) is a multi-objective utility function. In operational practice, utility would need to balance expected mission effect, probability of success, time, exposure, munitions expenditure, network burden, intelligence gain or loss, escalation, collateral risk, opportunity cost, and the value of preserving capabilities for future missions.

A production marketplace should not return only one opaque “optimal” answer. It should present a small Pareto set: for example, the fastest option, the lowest-risk option, the option that preserves scarce munitions, and the option most resilient to communications loss. The commander should see why each option was ranked, which assumptions are fragile, what data are stale, and which authorities remain unresolved. DoD policy’s requirements for transparent, auditable, and explainable technologies are directly relevant when marketplace recommendations feed weapon-system decisions. citeturn22view3

ACK also investigated marketplace scale, processing and bandwidth requirements, numbers of suppliers and consumers, constraint counts, Virtual Liaison representation, and planning horizon. Those questions are fundamental because naïvely enumerating every possible sensor, relay, processor, C2 node, and effector combination produces combinatorial growth. Practical systems require hierarchical searches, geographic and temporal pruning, reusable mission templates, and time-bounded optimization that returns a good feasible answer rather than waiting for mathematical optimality. citeturn18view0

Demonstrations, limitations, and policy implications

DARPA’s most clearly documented public demonstration occurred during the Air Force’s August–September 2020 ABMS on-ramp. The event involved aircraft, ships, air-defense batteries, and other assets. During an air-defense scenario, ACK reportedly analyzed thousands of possible cross-domain webs and recommended assets and a C2 play to the mission commander. After selection, the play was passed to C2IMERA and a Composite Tracker and Classifier integrated-fire-control system, which used automated messaging and Link 16 cuing to scramble fighters against cruise-missile targets. citeturn18view1

STITCHES was an essential but separate component. DARPA described it as a government-owned, software-only integration toolchain capable of generating low-latency, high-throughput middleware between heterogeneous systems without requiring hardware upgrades or changes to existing system software. It did not require all participants to adopt one common interface. In architectural terms, ACK answered “which capabilities should be combined and how should they be tasked?” while STITCHES helped answer “how can these particular systems exchange the required messages?” citeturn18view1

Industry work continued into later phases. BAE Systems publicly described scaling ACK software so that it could automatically identify assets across domains and assess the costs and benefits of using them during mission adaptation, with an objective of demonstrating the approach in a full-scale, operationally realistic setting. Because this is a contractor account rather than a released government test report, it should be treated as evidence of development activity, not independent confirmation of operational effectiveness. citeturn13view0

DARPA’s FY2025 budget justification characterized ACK as completed, reported $6 million in FY2023 funding and no subsequent program funding in that line, stated that it sought asset reallocation on the order of minutes, and said the technology transitioned to the Services. The public program page also states that ACK is complete. Neither source identifies operational units, deployed baselines, readiness levels, classified test results, or sustained performance under combat-representative cyber and electromagnetic attack. citeturn19view0turn18view0

Several limitations follow from the public evidence.

ACK was primarily a decision-aid and allocation program, not a complete kill-web infrastructure. It did not itself solve every transport, tactical waveform, cross-domain, identity, cloud, targeting-data, or weapon-interface problem. The 2020 demonstration depended on other C2 applications, Link 16, and STITCHES. Any operational implementation must integrate ACK-like orchestration with data fabrics, tactical networks, mission applications, security enforcement, and certified weapon-system interfaces. citeturn18view1

Marketplace state will always be imperfect. Availability reports may be delayed, communications may be partitioned, capacity may change after an offer is made, and adversaries may deceive sensors or attack capability advertisements. Recommendations therefore require validity intervals, confidence measures, provenance, revocation, and contingency plans. A system must be able to say “the option is no longer valid” rather than preserve a nominally optimal plan after its assumptions fail.

Dynamic composition enlarges the verification problem. A traditional integrated system can be tested against a relatively bounded configuration. A kill web may combine components that were never tested together in precisely that state, under that software version, network condition, or adversary behavior. RAND argued that procurement, evaluation, and fielding methods would need to change to cope with dynamic composition, and DoD autonomy policy requires realistic testing against adaptive adversaries, consideration of emergent behavior, and renewed testing after significant changes. citeturn19view7turn22view3

Resilience can conflict with efficiency. Maintaining extra sensors, routes, compute capacity, and weapons options consumes money, bandwidth, spectrum, manpower, and logistics. RAND’s immune-system analogy notes that abundance and redundancy may appear inefficient even though they create adaptability and survivability. Leaders must decide which missions justify true path diversity and which can accept lower-cost, less resilient architectures. citeturn19view8

The web increases cyber and counterintelligence exposure. More machine-readable capability data creates more information that an adversary could exploit to infer readiness, coverage gaps, munitions state, command relationships, or likely responses. A compromised marketplace could suppress legitimate options, advertise nonexistent capabilities, redirect missions toward ambushes, manipulate priorities, or create denial of service through fraudulent demand. DoD’s zero-trust approach—continuous verification, least privilege, microsegmentation, encryption, endpoint security, analytics, and auditing—is therefore a core mission requirement rather than an enterprise-information-technology add-on. citeturn19view5

Authorities may become the limiting latency rather than the network. A machine may discover a technically feasible chain in seconds, but the sensor data may not be releasable to the effector’s operator, the supplier may lack authority to accept the mission, the target may require additional identification, or the selected effect may require approval at a different echelon. ACK explicitly identified differing domain authorities and missions as a central challenge. Those constraints must be represented in machine-readable policy where possible, but policy automation cannot silently create authority that does not exist. citeturn18view0

Coalition operations require policy-aware interoperability. Technical compatibility is insufficient if partner systems cannot receive the source data, understand the confidence model, or legally employ the proposed effect. A coalition kill web will probably consist of federated national and mission networks with controlled information products rather than one homogeneous fabric. Data releasability, national caveats, export controls, and sovereignty over weapons employment must be first-class marketplace constraints.

Human-machine teaming requires calibrated trust. Operators must know whether a recommendation is based on fresh observations or predicted state, whether alternatives were excluded by policy or technical limits, and how sensitive the ranking is to uncertain inputs. RAND’s JADC2 analysis highlighted the need for new training, data stewards, distributed staff arrangements, and explainable decision support. citeturn19view10

At the institutional level, the kill web also changes acquisition incentives. A program optimized only for its parent platform may have little reason to expose capacity, publish interfaces, accept external tasking, or surrender proprietary control over data. MOSA requirements, interface ownership, conformance testing, data rights, and enterprise-level funding are therefore necessary to align program behavior with joint composability. DoD’s data strategy calls for future systems to include data interoperability, software upgradability, and cloud readiness as requirements, while its C3 strategy acknowledges that the desired shared data layer and common standards do not yet exist across the force. citeturn19view4turn22view2

The broader JADC2 context remains a work in progress. GAO reported in 2025 that DoD had produced a JADC2 Reference Architecture, a Reference Design addressing interoperable data modeling, campaign plans, and a 2024 capstone requirements document. GAO nevertheless concluded that further progress depended on a comprehensive framework to align organizations, capabilities, resources, and accountability. ACK should therefore be viewed as an influential technical demonstration of dynamic cross-domain composition, not proof that an enterprise-wide kill web has already been fully implemented. citeturn22view0

Assumptions, unresolved parameters, and implementation priorities

Several parameters necessary to produce final engineering requirements were not specified in the request and are not uniform across military missions.

Until those values are defined, the latency and availability figures in this report should be treated as engineering planning ranges, not operational requirements or authoritative standards.

A disciplined implementation sequence begins with a small number of end-to-end mission threads rather than an enterprise promise to connect everything. Each mission thread should define its effect, participants, authorities, data products, timing budget, degraded modes, security labels, and objective success criteria. The program should then expose key interfaces under MOSA, implement a canonical semantic model with adapters for legacy systems, deploy local-first edge services, and test the thread under loss, latency, stale data, spoofing, and conflicting resource demands.

The next step is to add a federated capability registry and ACK-like orchestration layer. Initial automation should focus on discovery, feasibility screening, and comparison rather than autonomous commitment. Recommendations should include rationale, assumptions, confidence, excluded alternatives, and resource consequences. Reservation and tasking can then be automated incrementally after authorities, conflict resolution, audit, and rollback behavior have been validated.

The final test should not be a scripted demonstration in which every component and interface is known in advance. A credible kill-web evaluation should remove nodes without notice, corrupt selected data, partition networks, introduce conflicting mission requests, alter authorities, exhaust resources, and require the force to compose an unplanned but safe alternative. Success is the continued production of authorized mission effects within required time and risk—not simply the exchange of messages among connected systems.

The decisive architectural principle is therefore: centralize what benefits from scale, federate what must cross organizations, and localize what must survive or meet a hard deadline. The decisive operational principle is: commanders retain responsibility for effects and authorities, while machines accelerate discovery, comparison, routing, and coordination. The decisive acquisition principle is: buy capabilities as replaceable contributors to a joint system, not as isolated platforms whose interfaces become permanent barriers. These principles are consistent with the direction of DARPA ACK, DoD JADC2, MOSA, the DoD Data Strategy, and zero-trust modernization, while recognizing that substantial interoperability, governance, and test challenges remain. citeturn18view0turn19view2turn19view4turn21search4turn19view5turn22view0