From Kill Chain to Kill Web: Operational Rationale, Technical Architecture, and the DARPA ACK Model

From Kill Chain to Kill Web: Operational Rationale, Technical Architecture, and the DARPA ACK Model

Executive Summary

The transition from a traditional kill chain to a kill web is best understood as a change in force architecture rather than the abandonment of sequential targeting. Air Force doctrine continues to define dynamic targeting through the Find, Fix, Track, Target, Engage, and Assess sequence—F2T2EA—commonly called the kill chain. A kill web surrounds that sequence with a larger, resilient system capable of composing many alternative chains from distributed sensors, decision services, communications paths, support capabilities, and effectors. The chain remains the mission process; the web supplies multiple ways to execute it. citeturn15view2turn15view1

The strategic reason for the shift is that tightly integrated, platform-specific chains are difficult to modify and can be defeated by disrupting a critical node or interface. DARPA’s Mosaic Warfare concept instead separates sensing, decision, and action functions so that commanders can choose among many authorized combinations. The resulting benefit is not merely faster targeting. It is optionality under attack: when a preferred sensor, headquarters, data path, or effector becomes unavailable, the force can discover and employ another valid combination rather than allowing the mission to fail with the broken link. citeturn15view1turn18view4

A functioning kill web requires considerably more than network connectivity. Its technical foundation must include a machine-readable capability model; a federated and governed data fabric; resilient multipath communications; distributed cloud and edge computing; mission-specific latency budgets; automated but constraint-aware orchestration; zero-trust identity and data security; human-machine decision support; modular interfaces for legacy integration; and continuous testing under realistic degradation. The Joint All-Domain Command and Control strategy treats common data standards, layered security, degraded-environment resilience, technology, authorities, processes, and people as parts of the same operational system. citeturn17view2turn16view1

No public DoD source establishes one universal kill-web latency requirement. Such a number would be technically inappropriate because different mission functions operate on different time scales. Embedded vehicle or weapon-control loops may require single-digit-millisecond response and should remain local; tactical cueing and fire-quality track exchange may require subsecond performance; human command decision support may tolerate several seconds; and cross-domain resource allocation of the type demonstrated by DARPA’s Adapting Cross-Domain Kill-Webs program operated on the order of minutes. The numeric targets in this report are therefore illustrative systems-engineering thresholds, not doctrinal requirements or disclosed ACK specifications. They should be replaced with mission-thread-specific values during requirements analysis. citeturn18view0turn18view1turn18view2turn17view1

DARPA’s Adapting Cross-Domain Kill-Webs—ACK—program addressed a narrower but crucial part of the problem: discovering capabilities across organizational boundaries, representing the tradeoffs associated with using them, and rapidly generating alternative sensor-effector-support combinations. ACK adapted commercial marketplace, sourcing, and supply-chain concepts; used bid-and-offer constructs; and combined them with a “Virtual Liaison” service abstraction. DARPA reports that ACK reduced asset-reallocation and assignment decisions to the order of minutes and that program technology transitioned to the military Services. Public sources do not identify all receiving programs, the precise fielded configurations, or the extent of operational deployment; those details remain unspecified in the unclassified record reviewed for this report. citeturn15view0turn17view0turn17view1

The principal executive conclusion is that a kill web should not be funded or governed as a single software product. It is a system-of-systems operating model requiring synchronized investment in data rights, interface standards, communications diversity, distributed computing, cybersecurity, command authorities, training, and test infrastructure. GAO’s assessment that DoD still needs a more comprehensive CJADC2 framework, common progress measures, and better mechanisms for sharing lessons illustrates the institutional risk: individual service solutions can improve local performance while leaving the joint enterprise fragmented. citeturn15view8

Scope and Analytical Basis

This report uses kill chain to mean an ordered operational process for producing and assessing an effect. In current Air Force targeting doctrine, F2T2EA is used for dynamic targeting and can involve kinetic or non-kinetic capabilities, including operations in cyberspace, space, the electromagnetic spectrum, and the information environment. The doctrine also makes clear that compressed timelines do not remove intelligence, legal-review, command-guidance, or consequence-assessment requirements. citeturn15view2turn16view0

Kill web is used here as an architectural and operational concept in which sensing, decision, support, communications, and effect capabilities are disaggregated and can be recombined into multiple mission-valid chains. DARPA’s Mosaic Warfare description emphasizes unbundling sense-decide-act functions and exposing numerous possible combinations, while ACK focused on selecting and reallocating elements within those combinations. Neither term should be interpreted as authorizing indiscriminate connectivity or autonomous employment of force. citeturn15view1turn15view0

JADC2 or CJADC2 is broader than a kill web. It includes the data, networks, analytics, command structures, policy, authorities, organizations, training, partner integration, and operational procedures required to sense, make sense, and act across domains. GAO characterizes CJADC2 as a DoD effort to connect selected—not necessarily all—assets across domains and with international partners, replacing manual “swivel-chair” data handling with more integrated information exchange. citeturn16view1turn15view8

The report relies primarily on public DARPA, DoD CIO, Joint Staff, Air Force doctrine, and DoD engineering sources, supplemented by GAO and RAND analysis. Because key operational parameters, cyber controls, data schemas, algorithms, and test results may be classified, descriptions below distinguish among three categories:

• Documented public facts, supported directly by primary sources.
• Architectural synthesis, derived from multiple official requirements.
• Recommended engineering targets, proposed for requirements development but not represented as official DoD or ACK thresholds.

The detailed internal design of ACK’s Virtual Liaison, the exact scoring functions used in its marketplace, service-specific transition recipients, operational test results, and current fielding scale are unspecified in the public sources reviewed. Assertions about those matters are therefore limited to what DARPA publicly disclosed or are explicitly identified as analytical interpretations. citeturn15view0turn17view1

Transition from Kill Chain to Kill Web

A traditional kill chain optimizes a predefined path. A sensor detects an object or event; data passes through designated processing and command nodes; a planned effector is assigned; the effect is delivered; and another sensor or reporting mechanism assesses the result. Each step may be technologically advanced, but the interfaces and organizational relationships are usually engineered and rehearsed as a relatively fixed set. Air Force doctrine recognizes that a single platform may sometimes perform all F2T2EA steps when it combines intelligence, surveillance, reconnaissance, weapons, and engagement authority, illustrating the most tightly coupled form of the chain. citeturn15view2

The difficulty is that tightly coupled systems are slow to adapt. DARPA described earlier system-of-systems integration as brittle because years of engineering could be needed to make one system communicate with another. A chain may therefore depend on one gateway, one headquarters, one proprietary data format, one communications relay, or one preassigned weapon. An adversary does not necessarily need to defeat every participating platform; it may be enough to disrupt the critical relationship among them. citeturn15view1

The kill-web approach changes the unit of integration from the platform to the capability and data service. A radar, aircraft, satellite, cyber element, command cell, communications relay, analytic service, or weapon can make selected functions available to the broader enterprise under defined policy and security constraints. Orchestration services then identify feasible combinations for a particular mission. A resulting engagement still proceeds through an ordered chain, but that chain is instantiated from a larger set of possibilities and can be recomposed when conditions change. citeturn15view0turn17view2

The shift is thus from:

• predetermined pairings to dynamic, policy-constrained combinations;
• platform-centric data ownership to governed data discoverability;
• centralized processing dependence to distributed cloud-edge execution;
• perimeter-based trust to identity-, device-, service-, and data-level trust;
• manual cross-organizational coordination to machine-assisted option generation; and
• success of one preferred chain to mission success despite loss of individual components.

These are architectural objectives rather than guarantees. A poorly governed “web” can create more attack paths, greater information overload, additional interoperability failures, and slower decision-making. Resilience arises only when redundancy, data semantics, authority, security, and failover behavior are intentionally engineered and tested. citeturn17view2turn17view3turn15view8

Visual metaphor. A traditional kill chain resembles a single railway line with fixed stations: it can move a train efficiently along the planned route, but a destroyed bridge or disabled signal box can halt the entire journey. A kill web resembles a metropolitan transit network. The destination and traffic laws remain fixed, but dispatchers can choose among several lines, transfer points, vehicles, and local control centers according to congestion, damage, capacity, and authorization. Not every station connects directly to every other station; shared maps, signaling standards, identity checks, operating rules, and transfer protocols make alternative routes usable. The metaphor also reveals the engineering burden: adding tracks without common signaling and traffic management creates chaos rather than resilience.

Comparative operating model

The comparison does not imply that every legacy system is inflexible or that every web component must communicate directly with every other component. DARPA’s formulation emphasizes possible combinations, while DoD’s JADC2 strategy calls for standardized interfaces and federated services rather than an uncontrolled all-to-all network. DoD’s current Modular Open Systems Approach similarly favors loosely coupled, severable components whose interfaces can be verified against widely supported standards. citeturn15view1turn17view2turn15view9turn15view10

Executive rationale and expected benefits

Resilience through substitution. If a preferred sensor, data path, processing node, or effector is lost, the architecture can search for another combination capable of satisfying the mission. DARPA described this as retaining options for completing a kill chain regardless of which individual element an adversary attacks. The operational requirement should be graceful degradation rather than perfect availability of every component. citeturn15view1

Decision advantage. A web can integrate more observations, reduce manual reconciliation, and generate several courses of action faster than human staffs can discover and compare them through liaison calls and disconnected applications. JADC2’s stated purpose is to improve the ability to sense, make sense, and act at the speed of relevance; RAND similarly identifies rapid data ingestion, fusion, transport, dynamic tasking, and resilient command and control as central objectives. citeturn16view1turn18view3

Utilization of latent capacity. An organization may have unused sensor time, communications capacity, analytic capability, or weapons availability that is invisible to another command. A capability marketplace can make selected capacity discoverable while allowing the owning organization to express constraints, opportunity costs, and mission priorities. ACK was explicitly designed around this cross-domain visibility and tradeoff problem. citeturn15view0

Faster adaptation and technology insertion. Modular interfaces and open standards allow new software, sensors, algorithms, or effectors to be integrated without reengineering every existing pairing. DoD’s MOSA guidance links severable modules and consensus-based interfaces to technology refresh, competition, innovation, and life-cycle affordability; recent Air Force open-architecture work likewise demonstrates decoupling mission software from specific vehicle hardware to reduce vendor lock. citeturn15view9turn15view10turn18view6

Cross-domain coordination without complete centralization. A web can expose capabilities to joint orchestration while leaving ownership, readiness management, and final release authority with the responsible organization. This is essential because the optimal technical combination may not be legally authorized, politically acceptable, operationally sustainable, or releasable to all partners. JADC2 therefore includes policies, processes, authorities, and human decision-making—not just networks and algorithms. citeturn15view0turn16view1turn18view4

The principal risks are also strategic. A force may become dependent on data it cannot verify, automation it cannot explain, commercial infrastructure it cannot reach, or interfaces it does not control. Excessive centralization can create lucrative targets, while excessive federation can produce inconsistent truth and conflicting tasking. GAO’s findings on fragmented investments, incomplete progress measures, uneven lesson-sharing, and overly restrictive classification indicate that institutional architecture is at least as important as technical architecture. citeturn15view8

Core Technical Requirements for a Functioning Military Kill Web

The following conceptual architecture synthesizes public JADC2, DoD data, cloud, zero-trust, MOSA, Mosaic Warfare, and ACK principles. It is not an official program diagram. The central design principle is governed composability: systems do not join merely because they are connected; they participate when their identities, interfaces, data, capabilities, authorities, and operational state satisfy the mission’s constraints. citeturn17view2turn17view3turn15view0turn15view10

flowchart LR
    subgraph Sources["Sensing and Information Sources"]
        ISR["ISR and platform sensors"]
        SPACE["Space, cyber, EMS, and partner sources"]
        INTEL["Intelligence and mission databases"]
    end

    subgraph Fabric["Federated Data and Trust Fabric"]
        META["Metadata, schemas, provenance, time, confidence"]
        DATA["Distributed data services and event streams"]
        ICAM["Identity, credential, access, and device trust"]
        CDS["Cross-domain and releasability controls"]
    end

    subgraph Compute["Cloud–Edge Compute Continuum"]
        EDGE["Platform and tactical-edge processing"]
        THEATER["Theater or regional cloud"]
        ENTERPRISE["Enterprise cloud and model services"]
    end

    subgraph Decision["Capability and Decision Layer"]
        REG["Capability registry and availability state"]
        ORCH["Constraint solver and orchestration"]
        POLICY["Authorities, ROE, priorities, and policy"]
        HMI["Commander decision aid"]
    end

    subgraph Action["Command, Action, and Assessment"]
        C2["Authorized C2 and tasking"]
        SUPPORT["Relay, PNT, logistics, and support"]
        EFFECT["Kinetic and non-kinetic effectors"]
        BDA["Assessment and feedback"]
    end

    ISR --> DATA
    SPACE --> DATA
    INTEL --> DATA
    META <--> DATA
    ICAM --> DATA
    CDS --> DATA

    DATA <--> EDGE
    DATA <--> THEATER
    DATA <--> ENTERPRISE
    EDGE <--> THEATER
    THEATER <--> ENTERPRISE

    DATA --> REG
    REG --> ORCH
    POLICY --> ORCH
    ORCH --> HMI
    HMI --> C2

    C2 --> SUPPORT
    C2 --> EFFECT
    SUPPORT --> EFFECT
    EFFECT --> BDA
    BDA --> DATA

Capability model

Purpose. The capability model tells the web what each participating organization, system, service, or asset can contribute without requiring every consumer to understand the provider’s internal implementation. ACK’s marketplace premise depended on consumers being able to request an outcome and suppliers being able to advertise capability, capacity, and quality of service across organizational and domain boundaries. citeturn15view0

Key attributes. A useful machine-readable capability record should contain a unique provider and capability identity; function or effect type; required inputs; produced outputs; geographic, temporal, environmental, and domain constraints; availability window; capacity; quality-of-service level; confidence; communications dependencies; security classification; releasability; owning authority; current workload; resource-consumption implications; and conditions under which the capability can be retasked. Sensitive performance details should be abstracted so that a consumer can judge fitness without receiving unnecessary source-and-method information. This attribute set is an analytical recommendation consistent with ACK’s publicly stated goal of advertising effects while protecting sensitive capability details. citeturn15view0

Implementation options. Programs can implement capability records as versioned schemas in a registry, graph-based service descriptions, standardized application programming interfaces, message-oriented advertisements, or combinations of these. Static characteristics may reside in an authoritative registry, while dynamic state—availability, location precision, health, capacity, and communications status—should be distributed through event streams or signed updates. A joint ontology should define high-level capability semantics, while service- or domain-specific extensions preserve necessary detail.

Risks. The catalog can become inaccurate, excessively classified, too detailed to scale, or too abstract to support meaningful matching. A stale advertisement can cause orchestration to assign a resource that is unavailable. An overexposed record can reveal readiness, location, or system vulnerabilities. Different services may use the same term for different capabilities or different terms for equivalent capabilities. An optimizer may also equate nominally similar services whose operational quality differs substantially.

Recommended metrics. Measure the percentage of mission-relevant capabilities represented; metadata and semantic-conformance rate; median and 99th-percentile time to publish a state change; stale-record rate; percentage of records with current authority and releasability labels; capability-match precision and recall against operator judgment; failed taskings caused by inaccurate advertisements; and information-exposure incidents. For time-sensitive entries, the program should establish a maximum allowable state age rather than treating catalog correctness as a binary property.

Federated data fabric

Purpose. The data fabric enables authorized users and services to discover, understand, access, exchange, and process data across domains, echelons, organizations, and security levels without requiring all information to be stored in one database. The JADC2 strategy’s working definition is a federated DoD data environment that shares information through interfaces and services, supported by common standards and architectures. citeturn17view2

Key attributes. Required attributes include authoritative source identification; consistent metadata; schema and interface versioning; precise time stamps; provenance; confidence and uncertainty; data-quality indicators; data lineage; geospatial and temporal references; classification and releasability labels; retention and dissemination rules; machine-readable access policy; and mechanisms for reconciling conflicting observations. The DoD Data Strategy’s VAULTIS principles—visible, accessible, understandable, linked, trustworthy, interoperable, and secure—provide an appropriate evaluation framework. citeturn15view5

Implementation options. A kill web can combine domain data meshes, publish-subscribe event buses, streaming platforms, federated query services, object stores, graph databases, tactical caches, data-product application programming interfaces, and cross-domain gateways. A common canonical model may be useful for high-value shared objects, such as tracks, tasks, capabilities, and authorities, while mediation services translate less common data. Full physical centralization is neither required nor desirable; policy-controlled data products may remain with their authoritative owners and be retrieved, replicated, or subscribed to as mission needs dictate.

Risks. A universal schema can become too slow to change, while unrestricted local schemas recreate stovepipes. Federation can produce contradictory versions of truth, hidden dependencies on remote services, and uncontrolled data duplication. Classification and releasability practices can prevent technically compatible systems from exchanging useful information; GAO identifies overly restrictive classification as a significant obstacle to CJADC2 data sharing. Poor provenance can allow false, spoofed, or low-confidence data to contaminate downstream decisions. citeturn15view8

Recommended metrics. Track metadata completeness; schema-conformance rate; percentage of data products with authoritative-source and provenance information; discovery success rate; access-request success by authorized user class; 95th- and 99th-percentile data age; cross-domain transfer delay; duplicate and conflict rates; data-quality defect rate; lineage completeness; time to onboard a new data producer; time to revoke or alter access; and the percentage of mission threads able to operate from cached or replicated data during disconnection.

Resilient communications

Purpose. The communications layer transports commands, capability state, sensor observations, decision products, and assessment data through contested and degraded environments. JADC2 explicitly requires resilience in degraded electromagnetic conditions, while the OCONUS Cloud Strategy calls for robust, secure, redundant transport and support for disconnected, intermittent, and limited-bandwidth—D-DIL—users. citeturn17view2turn16view2

Key attributes. The network should provide route diversity; heterogeneous waveform and bearer support; policy-aware routing; message prioritization; quality-of-service enforcement; multicast or publish-subscribe delivery where appropriate; store-and-forward operation; intermittent synchronization; anti-jam and low-probability-of-detection considerations; cryptographic protection; traffic-flow protection; and rapid failover. It must distinguish data that is essential to immediate mission execution from information that can be delayed, compressed, summarized, or discarded.

Implementation options. Potential components include line-of-sight tactical data links, airborne and terrestrial relays, military and commercial satellite communications, software-defined wide-area networking, mobile ad hoc or mesh networks, directional links, delay-tolerant networking, protocol gateways, content-aware routing, and local mission-data caches. Air Force TOC-Light illustrates the operational demand for compact forward-deployed C2 infrastructure where persistent connectivity and large server installations are unavailable. citeturn18view5

Risks. More links do not automatically create more resilience. Shared dependencies—common satellites, ground stations, timing sources, cryptographic infrastructure, commercial providers, or spectrum bands—can produce correlated failure. Aggressive retransmission can saturate limited channels. Routing optimization may expose platform location or emissions. Gateways can become bottlenecks and high-value cyber targets. A network designed around steady-state throughput may fail under burst demand during a crisis.

Recommended metrics. Measure route and bearer diversity; percentage of traffic with two or more independent paths; end-to-end deadline-delivery ratio; 95th- and 99th-percentile latency and jitter; effective throughput under interference; packet and message-loss rate; time to detect a failed path; time to reroute; mission completion during specified bandwidth reductions; duration of disconnected operation; synchronization recovery time; electromagnetic exposure; and the number of common-mode dependencies remaining in each critical mission thread.

Cloud and edge continuum

Purpose. The cloud-edge continuum places processing, data, and decision services where they can meet mission deadlines and survive communications disruption. Enterprise environments are well suited to global aggregation, historical analysis, model development, and software distribution; theater environments can coordinate regional operations; tactical-edge nodes perform local fusion, inference, caching, and decision support; and platform-resident systems retain safety- and mission-critical functions that cannot depend on external connectivity. citeturn15view4turn16view2

Key attributes. Workloads should be portable, signed, observable, and capable of operating with bounded dependencies. Data should be staged in advance for expected disconnected operation. Edge services require local identity and policy caches, synchronization rules, model and software version control, resource-aware scheduling, rollback capability, and clear procedures for resolving conflicting updates after reconnection. DoD strategy specifically calls for enough forward-deployed data to support disconnected users and for seamless reintegration when communications return. citeturn16view2

Implementation options. Architectures may use containerized or otherwise portable services; lightweight orchestration on tactical nodes; theater and enterprise cloud regions; platform-resident accelerators; replicated event logs; local databases; content-distribution mechanisms; infrastructure as code; DevSecOps pipelines; and prepositioned model packages. Workload placement can be static for safety-critical functions, policy driven for predictable missions, or adaptive when computing resources and network paths change.

Risks. Cloud concentration creates high-value targets and long-haul dependencies. Edge proliferation increases patching, configuration, supply-chain, and physical-security burdens. Inconsistent software or model versions can cause different nodes to produce different recommendations. Synchronization after disconnection can overwrite valid local decisions or propagate corrupted data. Resource-constrained edge devices may also lack the compute, cooling, or power needed for sophisticated models.

Recommended metrics. Track disconnected endurance by mission class; percentage of mission-essential services available locally; edge startup and recovery time; workload migration time; software and model-version divergence; synchronization backlog; data-conflict rate after reconnection; local decision-service availability; compute, memory, power, and storage utilization; time to distribute and roll back an update; and the percentage of critical workloads that continue when enterprise and theater-cloud access is removed during testing.

Mission-specific latency budgets

Purpose. A latency budget allocates the maximum allowable time among sensing, preprocessing, transmission, ingestion, fusion, option generation, human or delegated authorization, tasking, and receiving-system response. It prevents a program from declaring success based on fast network transport while the complete mission thread still misses its operational deadline.

There is no publicly disclosed universal DoD kill-web latency threshold. The JADC2 strategy refers to action at the “speed of relevance,” and public technical benchmarks demonstrate why timing must be mission specific: ITU material identifies a one-millisecond over-the-air research target for some ultra-low-latency communications, while NIST industrial studies distinguish sub-millisecond or few-millisecond closed-loop control from sub-100-millisecond supervisory control and subsecond monitoring. These civilian values are not military requirements, but they establish useful orders of magnitude for engineering decomposition. citeturn16view1turn18view0turn18view1turn18view2

The following values are illustrative starting points for requirements analysis. Mission type, geography, threat, communications path, command authority, and platform dynamics are unspecified by the user; therefore, these thresholds should not be interpreted as universal acceptance criteria.

The embedded-control values are informed by publicly available communications and industrial-control timing references, not disclosed weapon-system specifications. The ACK allocation range is anchored in DARPA’s public statement that asset-reallocation and assignment decisions were accelerated to the order of minutes. citeturn18view0turn18view1turn18view2turn17view1

Key attributes. Every latency requirement should define start and stop events, percentile, maximum deadline, data size, network condition, processing configuration, geography, security processing, and whether human decision time is included. “Average latency” is insufficient because rare deadline misses can dominate operational risk. Age of information, jitter, clock error, and probability of delivery before the deadline should accompany the headline number.

Implementation options. Options include edge preprocessing; event prioritization; local correlation; deterministic networking for bounded local systems; data compression; adaptive fidelity; prepositioned data; parallel processing; geographically distributed services; preapproved decision authorities; speculative option generation; and mission-aware routing. System architects should maintain separate latency budgets for raw sensing, fused tracks, alerts, command decisions, and tasking rather than applying one service-level objective to all traffic.

Risks. Arbitrary “real-time” requirements can make systems unaffordable, while permissive averages can hide unacceptable tail latency. Speed-of-light delays, satellite routing, encryption, cross-domain inspection, retransmission, and human authorization all consume budget. Optimizing only for latency can reduce assurance, provenance, or security. Faster data may also be less accurate; the architecture must manage the trade between freshness and confidence.

Recommended metrics. Use 50th-, 95th-, 99th-, and 99.9th-percentile end-to-end latency; hard-deadline miss rate; age of information at decision time; jitter; clock-synchronization error; processing and transport contribution by stage; failover latency; time to detect stale data; and mission-outcome sensitivity to delayed or missing inputs. Test results should report performance under nominal, congested, jammed, disconnected, and cyber-degraded conditions.

Automated orchestration and constraint solving

Purpose. Orchestration converts a requested operational effect into feasible combinations of sensing, communications, processing, support, command, and effect capabilities. It reduces the manual burden of discovering resources across services and enables rapid substitution when a preferred component becomes unavailable. ACK was specifically aimed at this tasking and retasking problem. citeturn15view0

Key attributes. The solver must evaluate functional compatibility, timing, location, communications reachability, capacity, resource conflicts, readiness, quality of service, classification, releasability, command relationships, rules of engagement, mission priority, risk, and opportunity cost. It should generate several valid options rather than only a single opaque recommendation. Every option should identify assumptions, binding constraints, uncertainty, dependencies, expected mission value, and effects on other commitments.

Implementation options. Candidate techniques include constraint programming, mixed-integer optimization, graph search, market-clearing algorithms, auction mechanisms, multi-objective optimization, rule engines, planning systems, and machine learning used within bounded roles. Deterministic policy checks should validate any statistically generated recommendation. A hybrid architecture may use optimization to construct feasible options, simulation to estimate outcomes, and learned models to predict performance or risk.

Risks. The solver may optimize the wrong objective, rely on stale capability data, overlook an authority restriction, or produce options that are mathematically feasible but operationally unrealistic. Optimization at enterprise scale may be computationally expensive. A single objective such as speed can consume scarce weapons, expose critical sensors, interfere with higher-priority missions, or increase escalation risk. Adversaries may also manipulate input data to influence recommendations.

Recommended metrics. Measure time to first feasible option; time to a ranked option set; percentage of options free of policy and resource conflicts; constraint-violation rate; option diversity; optimality gap where a benchmark solution is available; substitution time after failure; percentage of recommendations accepted, modified, or rejected by commanders; explanation completeness; sensitivity to uncertain inputs; computational scaling with suppliers, consumers, and constraints; and downstream mission success rather than algorithm speed alone.

Zero-trust security and cross-domain protection

Purpose. Zero trust limits the damage that a compromised participant can cause in a highly connected environment. It replaces assumptions based on network location with continuous, transaction-specific decisions about users, devices, applications, workloads, data, and current risk. DoD’s strategy is organized around seven pillars and emphasizes dynamic policy, multi-attribute confidence, least-privilege access, rapid containment, auditability, and defense of data, applications, assets, and services. citeturn17view3turn15view6

Key attributes. A kill web needs strong machine and human identity; credentialing; device and workload attestation; encrypted communications; data-level labels; attribute- and policy-based access control; microsegmentation; continuous risk assessment; endpoint monitoring; tamper-evident audit logs; software-supply-chain assurance; rapid credential revocation; and approved cross-domain solutions. Authorization should incorporate mission, role, organization, device condition, data classification, releasability, geography, time, and current threat state.

Implementation options. Architectures can use federated identity and credential services, hardware roots of trust, signed workloads and data products, service meshes, policy decision and enforcement points, microsegmented overlays, local policy caches, behavioral analytics, automated isolation, and one-way or bidirectional cross-domain mechanisms appropriate to the information flow. Tactical nodes require bounded offline authorization so that temporary disconnection does not disable essential functions.

Risks. Central identity or policy services can become single points of failure. Excessive authentication and inspection can consume latency and bandwidth. Offline credentials can remain valid after compromise. Misconfigured policy can either expose sensitive information or prevent legitimate mission use. Cross-domain gateways can become bottlenecks, and excessive collection for behavioral analytics can create privacy, retention, and insider-risk concerns.

Recommended metrics. Measure percentage of users, devices, workloads, and data products under continuous authorization; least-privilege-policy coverage; unauthorized-access attempts blocked; mean time to detect, contain, and revoke a compromise; segmentation effectiveness; credential and policy-propagation time; offline-authorization duration and scope; audit-log completeness; cryptographic compliance; cross-domain transfer success and delay; false-positive denial rate; and mission continuity after identity, directory, or policy-service loss.

Human-machine decision support

Purpose. Human-machine decision support converts complex, rapidly changing network information into understandable options while preserving command responsibility and lawful authorization. Air Force doctrine requires intelligence sufficiency, legal review, desired-effect analysis, consequence consideration, and commander guidance; automation can accelerate data handling but does not eliminate those obligations. citeturn15view2

Key attributes. The interface should disclose why each option was generated, which data sources support it, the age and confidence of those inputs, required authorities, expected effects, resource tradeoffs, communications dependencies, failure modes, and alternatives. It should distinguish facts from predictions, display disagreement among sources, and make uncertainty visible. Operators need the ability to modify constraints, reject recommendations, inspect dependencies, and record the rationale for decisions.

Implementation options. Useful mechanisms include ranked course-of-action displays, provenance drill-down, confidence visualization, natural-language summaries backed by structured data, mission-impact simulation, alerts based on thresholds, counterfactual explanations, and collaborative decision workspaces. Interfaces should be tailored to role and echelon; a tactical controller, legal adviser, intelligence analyst, component commander, and joint-force commander require different abstractions.

Risks. More information can increase rather than reduce cognitive burden. Operators may over-trust polished recommendations, under-trust unfamiliar automation, or anchor on the first option shown. Confidence scores may be misunderstood as probabilities of mission success. Automation can conceal data-quality defects, compress genuine disagreement into a single ranking, or cause commanders to act faster than organizational and legal safeguards can function.

Recommended metrics. Measure time to comprehend and decide; option-comparison accuracy; operator ability to identify uncertainty and binding constraints; false-alert and missed-alert rates; workload using validated human-factors instruments; appropriate reliance on automation; recommendation override and modification rates; explanation-use rate; decision quality in blinded scenarios; handoff performance among roles; and post-mission calibration between predicted and actual outcomes.

Legacy integration and modular open architecture

Purpose. Legacy integration permits existing platforms and mission systems to participate without requiring simultaneous replacement of the force. The engineering objective is to wrap, mediate, or selectively modernize legacy interfaces while ensuring new systems do not create another generation of proprietary stovepipes.

Key attributes. Required characteristics include documented interfaces; modular boundaries; versioned data contracts; protocol translation; conformance testing; replaceable adapters; data-rights provisions; configuration management; backward compatibility where operationally necessary; and a clear distinction between open interfaces and openly accessible operational data. DoD MOSA guidance defines the approach as a combined technical and business architecture using widely supported standards where suitable and allowing components to be incrementally added, removed, or replaced. citeturn15view9turn15view10

Implementation options. Programs may use gateways, middleware, API façades, message brokers, protocol translators, data adapters, virtualization, digital twins for interface testing, and government-owned reference architectures. DARPA testimony described STITCHES as automatically generating middleware among heterogeneous systems without forcing every participant to adopt one common interface, illustrating a mediation approach that can complement—not replace—common standards. citeturn18view7

Risks. Adapters can preserve obsolete semantics, conceal poor data quality, add latency, and become permanent technical debt. Proprietary data rights can prevent competition or independent verification. A nominally “open” interface may still be controlled by one vendor or lack a conformance test. Excessive backward compatibility can prevent modernization, while aggressive replacement can disrupt operationally proven systems.

Recommended metrics. Measure time and cost to integrate a new producer, consumer, sensor, or effector; percentage of integrations using reusable rather than bespoke adapters; interface-conformance pass rate; adapter defect rate; end-to-end latency added by mediation; supported-version span; component substitution time; number of qualified vendors per module; government access to necessary interface and test data; and percentage of mission threads affected by each gateway’s failure.

Continuous testing, verification, and operational experimentation

Purpose. Testing establishes whether the web continues to achieve mission outcomes when systems, networks, data, and organizations behave imperfectly. DARPA’s Mosaic Warfare leadership emphasized that commanders will not trust the concept without demonstration, while JADC2 strategy and GAO analysis both point to the need for experimentation, measurement, and shared lessons. citeturn15view1turn15view8

Key attributes. Test programs should be mission-thread based, threat informed, repeatable, instrumented, and progressively realistic. They must evaluate not only functional interoperability but also cyber resilience, degraded communications, data integrity, timing, human performance, authority handoffs, coalition releasability, logistics, and recovery. Testing should include independent verification and validation of critical algorithms, interfaces, and safety constraints.

Implementation options. A comprehensive approach can combine modeling and simulation, digital engineering, hardware-in-the-loop laboratories, live-virtual-constructive environments, cyber ranges, communications-emulation facilities, red teams, operational exercises, continuous integration tests, interface certification laboratories, and field experiments. Synthetic data and simulated assets can enlarge scenario coverage, but live systems and operational users are needed to uncover real integration and human-factors problems.

Risks. Demonstrations can be scripted around favorable conditions and conceal dependencies that fail at scale. Classified restrictions may prevent realistic coalition testing. Test ranges may not reproduce actual jamming, congestion, cyber compromise, or geography. Algorithms can overfit known scenarios. Separate service experiments may generate lessons that are not shared, a concern identified by GAO. citeturn15view8

Recommended metrics. Evaluate mission-thread completion probability under nominal and degraded conditions; graceful-degradation curves as nodes and bandwidth are removed; time to detect and replace a failed component; recovery time; deadline-delivery rate; interoperability-conformance rate; cyber-compromise containment; percentage of scenarios exercising alternative routes; human decision quality; false-option generation; data-corruption tolerance; repeatability; test-coverage traceability to requirements; and the rate at which identified deficiencies are corrected and retested.

The most important aggregate measure is not network uptime. It is probability of accomplishing a defined mission within its operational deadline, authority constraints, and acceptable risk after one or more components have been denied, degraded, deceived, or destroyed.

DARPA ACK Program

Purpose and problem definition

DARPA established ACK to provide mission commanders with decision aids for rapidly identifying and selecting options to task and retask assets within and across organizational boundaries. The program addressed sensors, effectors, and support elements across space, air, land, surface, subsurface, and cyber domains. DARPA contrasted this adaptive approach with monolithic, predefined kill chains. citeturn15view0

DARPA identified three central problems:

1. Commanders had limited visibility into capabilities, available capacity, and quality of service outside their own domain.
2. Capability-owning organizations had their own missions and authorities, making it difficult to evaluate the cost or value of supporting another organization’s request.
3. Decision-makers needed a rapid method to compare many cross-domain options and select the most appropriate combination.

These are not merely search problems. They combine resource allocation, organizational incentives, policy constraints, operational risk, timing, and uncertainty. citeturn15view0

Capability-marketplace mechanics

ACK adapted concepts from e-commerce, sourcing, and supply-chain management. In commercial terms, a consumer states demand, suppliers describe offers, a marketplace matches supply to demand, and a decision mechanism evaluates price and quality. In ACK, however, the “product” is a military capability or effect, and “cost” may represent scarcity, mission displacement, risk, timing, resource consumption, or the consequences of diverting an asset—not necessarily money. citeturn15view0turn17view1

A conceptual mapping is shown below.

The marketplace is therefore not an unrestricted exchange. Every bid and offer must remain bounded by command authority, security, releasability, mission priority, and operational feasibility. DARPA’s public ACK description states that the program investigated bid-and-offer language, processing and bandwidth needs, marketplace scale, Virtual Liaison representations, and planning horizons, indicating that the program treated scalability and architectural representation as research questions rather than solved assumptions. citeturn15view0

Virtual Liaison role

DARPA publicly describes the Virtual Liaison as a service abstraction used with the larger Capability Marketplace. Public sources do not provide a complete software specification. The most defensible interpretation is that the Virtual Liaison acted as a controlled intermediary between an organization’s internal resources and the marketplace, analogous to a human liaison officer who understands local capabilities, priorities, constraints, and authorities. citeturn15view0

Under that interpretation, a supplier-side Virtual Liaison could translate local resource state into bounded offers, withhold sensitive internal details, evaluate whether a request was supportable, express opportunity costs, and enforce organizational policy. A consumer-side Virtual Liaison could translate commander intent into a structured request, specify required service levels, and mediate negotiation or option refinement. These functions are an architectural inference from the published marketplace description; exact ACK implementation details are unspecified publicly.

The abstraction is important because a wholly centralized optimizer would otherwise need direct access to every organization’s detailed resources, policies, and mission plans. Virtual Liaisons permit decentralized ownership: the marketplace can ask what an organization can provide, while the organization retains authority over how and whether it supplies the capability. ACK also sought to let providers advertise achievable effects without revealing sensitive sources and methods. citeturn15view0

ACK marketplace flow

The following diagram is a public-source-based conceptual reconstruction, not an official DARPA software diagram.

flowchart TD
    CMD["Mission commander defines desired effect,
    timing, priority, and constraints"]

    CVL["Consumer Virtual Liaison
    structures the request"]

    MARKET["Capability Marketplace
    publishes bid or request"]

    SVL1["Supplier Virtual Liaison A"]
    SVL2["Supplier Virtual Liaison B"]
    SVL3["Supplier Virtual Liaison C"]

    OFFERS["Abstract capability offers:
    capacity, QoS, constraints, and cost"]

    SOLVER["Feasibility and trade-space engine:
    compatibility, timing, authority,
    communications, risk, and opportunity cost"]

    OPTIONS["Ranked cross-domain options
    with assumptions and tradeoffs"]

    APPROVAL["Commander and responsible authorities
    review, modify, and approve"]

    TASK["Existing C2 systems issue
    authorized tasking"]

    EXEC["Sensors, support elements,
    and effectors execute"]

    FEEDBACK["Status, assessment, and
    capability-state feedback"]

    CMD --> CVL
    CVL --> MARKET

    MARKET --> SVL1
    MARKET --> SVL2
    MARKET --> SVL3

    SVL1 --> OFFERS
    SVL2 --> OFFERS
    SVL3 --> OFFERS

    OFFERS --> SOLVER
    SOLVER --> OPTIONS
    OPTIONS --> APPROVAL
    APPROVAL --> TASK
    TASK --> EXEC
    EXEC --> FEEDBACK

    FEEDBACK --> MARKET
    FEEDBACK --> CMD
    MARKET --> SOLVER

The flow separates decision aid from command execution. ACK’s published purpose was to help select kill-chain elements and assign roles; it was not publicly characterized as replacing command authority, targeting doctrine, legal review, or the systems that transmit and execute military orders. citeturn17view1turn15view2

ACK workflow and principal actors

The workflow combines facts from DARPA’s ACK description and budget justification with a systems-engineering reconstruction of the actions needed to operationalize those facts. citeturn15view0turn17view0turn17view1turn15view2

Demonstration context and related technology

DARPA testimony concerning Mosaic Warfare described ACK and the System-of-systems Technology Integration Tool Chain for Heterogeneous Electronic Systems—STITCHES—within an Air Force Advanced Battle Management System on-ramp. In the reported air-defense scenario, ACK analyzed thousands of options and recommended assets and a command-and-control “play,” while STITCHES generated middleware needed to exchange data among heterogeneous systems. The pairing illustrates two different architectural functions: ACK supported what should be combined, while STITCHES supported how otherwise incompatible systems could exchange information. citeturn18view7

That distinction remains important for acquisition. A marketplace can identify a theoretically excellent sensor-effector combination, but the option is unusable if the systems cannot exchange data, if the network cannot meet the deadline, or if command authorities cannot be passed. Conversely, middleware can connect two systems without determining whether their combination is operationally desirable. A functioning kill web requires allocation, integration, transport, security, authority, and human decision support to work together.

Limitations

ACK did not constitute the complete kill web. It addressed decision support, capability discovery, tradeoff analysis, and resource allocation. It did not by itself provide all tactical communications, cloud infrastructure, data standards, cybersecurity controls, targeting authorities, or platform interfaces required for operational execution. citeturn15view0turn17view1

Marketplace scale was an explicit research issue. DARPA identified the number of consumers, suppliers, constraints, bandwidth demands, processing needs, and planning horizon as matters to be characterized. Optimization performance demonstrated in one scenario should therefore not be assumed to extend unchanged to a global marketplace with thousands of dynamic resources, coalition restrictions, and adversarial data conditions. citeturn15view0

Capability advertisements can become stale or strategically sensitive. A useful marketplace needs current availability and quality information, but publishing detailed resource state may reveal readiness, location, tactics, or shortages. Abstraction protects sensitive information but can also remove details needed to distinguish nominally similar options.

Cost functions are politically and operationally complex. The opportunity cost of diverting a sensor, aircraft, cyber capability, or weapon cannot always be expressed through one numeric score. It may depend on classified plans, escalation concerns, legal restrictions, future missions, logistics, alliance commitments, or commander risk tolerance.

Technical feasibility does not create authority. A solver may find a physically and digitally compatible combination that is prohibited by rules of engagement, classification, national caveats, command relationships, or weapon-release authority. The marketplace therefore requires machine-readable policy where possible and explicit human resolution where policy is ambiguous.

Optimization can hide assumptions. Commanders need to know why an option ranks highly, which inputs are uncertain, which other missions are displaced, and what occurs if an element fails. An unexplained ranking is inadequate for consequential command decisions.

The public record does not establish autonomous use-of-force authority. ACK is described as a decision aid for commanders. Public sources do not support characterizing it as an autonomous weapons controller or as a system independently deciding whether force should be employed. citeturn15view0turn17view1

Transition outcomes

DARPA’s fiscal year 2025 budget justification states that ACK accelerated asset-reallocation and assignment decisions to the order of minutes, produced automated tools and decision aids for selecting kill-chain elements and assigning roles and responsibilities, and transitioned technology to the military Services. The same budget entry shows fiscal year 2023 funding and no subsequent ACK funding in the displayed fiscal year 2024 and 2025 columns, consistent with program completion. citeturn17view1

DARPA’s current program page also identifies ACK as complete. Public documentation reviewed for this report does not specify all transition recipients, contract vehicles, program-of-record integrations, fielded unit quantities, classified operational evaluations, or whether a single common ACK implementation remains in service. “Transitioned to the Services” should therefore be interpreted as evidence of technology transfer, not by itself as proof of enterprise-wide deployment or operational maturity. citeturn15view0turn17view1

The most enduring transition outcome may be architectural rather than product specific: ACK demonstrated that cross-domain resource allocation can be framed as a decentralized market in which capability owners expose bounded offers, commanders express demand, and automation compares numerous combinations. That pattern can be reused in broader CJADC2 environments, but only when connected to authoritative data, resilient networks, modular interfaces, cyber controls, command authorities, and trained operators.

Findings and Decision Implications

The kill chain and kill web are complementary, not competing, concepts. F2T2EA remains a disciplined sequence for developing, engaging, and assessing targets. The kill web is the enabling architecture that makes more than one valid F2T2EA path available and permits the force to change paths when the preferred one is disrupted. citeturn15view2turn15view1

For executives, the most consequential change is from buying isolated platforms to governing a portfolio of composable capabilities. Platform performance remains important, but enterprise value increasingly depends on whether data, software, interfaces, security attributes, and command relationships permit the platform’s capabilities to be used outside its original vertical stack. MOSA and data-rights provisions are therefore operational-resilience mechanisms, not merely acquisition-efficiency measures. citeturn15view9turn15view10

For technical leads, the primary architectural rule should be: do not close a safety-critical or terminal-control loop over infrastructure whose latency, availability, security, and authority cannot be bounded. Keep millisecond-class control local; use the wider web to provide tasking, cues, shared state, alternatives, and intent. Allocate latency, assurance, and autonomy according to mission class rather than imposing a single enterprise service level.

For data leaders, interoperability should be measured by successful mission-thread exchange, not the existence of a common data lake or API. The data fabric must preserve provenance, time, confidence, classification, releasability, and policy. A rapidly delivered observation without source, age, or uncertainty may be operationally worse than a slower but trusted data product. citeturn17view2turn15view5

For cyber leaders, greater connectivity must be paired with smaller trust zones and finer-grained authorization. A kill web should assume compromised nodes, credentials, and data sources and should contain their effects through dynamic policy, microsegmentation, workload and device assurance, data-level security, rapid revocation, and continuous monitoring. citeturn17view3turn15view6

For command-and-control leaders, machine-readable authorities are as important as machine-readable capabilities. A system cannot rapidly recompose if it discovers an alternative but must then resolve command relationships, release authority, national caveats, or classification rules manually. Some authorities can be predetermined, delegated, or expressed as policy; others will remain inherently judgment based and must be clearly presented to human decision-makers. citeturn18view4turn15view2

For test organizations, the decisive question is not whether all nodes remain connected. It is whether the force can continue to achieve a defined effect when preferred nodes are removed and information is delayed, contradictory, spoofed, or unavailable. Test campaigns should deliberately break the preferred chain, measure time to discover and approve a substitute, and verify that the alternative remains lawful, secure, and within the mission deadline.

ACK’s contribution should therefore be understood precisely. It showed how marketplace concepts and Virtual Liaison abstractions could improve cross-domain discovery, comparison, and allocation of capabilities. It did not eliminate the need for a data fabric, resilient transport, cloud-edge processing, zero trust, modular interfaces, human command, or doctrine. Its publicly reported “order of minutes” outcome is appropriate for force allocation and recomposition; it should not be misrepresented as a threshold for terminal engagement or platform control. citeturn15view0turn17view1

The recommended programmatic sequence is to define priority mission threads first; assign authorities and human decision points; identify required capability and data contracts; establish mission-specific latency and resilience budgets; design cloud-edge placement and communications paths; implement identity and data policy; integrate through verifiable modular interfaces; and then evaluate orchestration algorithms against operational outcomes. Starting with an enterprise “connect everything” initiative risks producing an expensive network with no reliable method for deciding what data matters, what combinations are authorized, or whether the resulting mission thread will complete on time.

The final analytical judgment is that a military kill web is viable only when composability is bounded by trust, authority, semantics, timing, and operational evidence. Without those controls, it is merely a larger network. With them, it can turn the loss of a preferred chain from a mission-ending event into a manageable resource-allocation problem.