Kill Webs as the Operational Engine of Joint All-Domain Command and Control

Kill Webs as the Operational Engine of Joint All-Domain Command and Control

Executive summary

A kill chain is a sequential mission process—commonly expressed for dynamic targeting as find, fix, track, target, engage, assess—in which each stage depends on successful completion of the preceding stage. A kill web preserves those targeting functions but changes their topology: multiple sensors, command nodes, communications paths, analytic services, and lethal or nonlethal effectors can be recombined dynamically. Marine Corps targeting doctrine explicitly describes kill webs as multiple possible sensor-and-engagement combinations that allow a mission to continue despite the loss or interruption of a node. citeturn16search0turn16search2

Joint All-Domain Command and Control, or JADC2, is broader than a kill web. JADC2 is the Department of Defense’s enterprise approach for enabling the Joint Force to “sense, make sense, and act” across domains, echelons, and mission partners. It encompasses data, technical architecture, personnel, doctrine, authorities, security, training, and nuclear-command integration—not merely target prosecution. A kill web is best understood as an operational mission thread running through that larger JADC2 ecosystem. citeturn13view0turn17view6

The central contribution of kill-web thinking is optionality under disruption. Instead of binding a particular sensor to a particular command post and shooter, the force represents sensors, tracks, decision authorities, communications routes, and effects as substitutable—or at least partially substitutable—services. When one radar is jammed, a satellite track, passive airborne sensor, allied radar, or another ground sensor may preserve custody. When one network is unavailable, data can move over a different tactical data link, satellite path, terrestrial transport, or store-and-forward edge service. When one shooter is outside range, lacks weapons, or does not have authority, another authorized effector can be nominated. DARPA’s Adapting Cross-Domain Kill-Webs program similarly framed the problem as helping commanders rapidly identify and retask assets across organizational boundaries. citeturn18search11turn16search2

Five mechanisms make this possible:

1. Common data semantics and interfaces make observations understandable across systems. Metadata must communicate time, position, uncertainty, source provenance, classification, releasability, and confidence—not just a coordinate.
2. Federated data fabrics and messaging services make data discoverable and distributable without requiring every platform to maintain bespoke point-to-point interfaces with every other platform.
3. Role-tailored common operating pictures let air, maritime, land, space, cyber, intelligence, and coalition users view a consistent underlying data set while receiving only the detail appropriate to their mission and authorization.
4. Resilient transport and edge processing reduce dependence on central clouds and headquarters, prioritizing compact track updates and mission commands over bandwidth-intensive raw sensor products.
5. Machine-assisted decision support, bounded by command authority, continuously evaluates sensor quality, communications health, target confidence, available effects, rules of engagement, risk, and timing. It recommends and reroutes; it does not inherently transfer legal command authority or eliminate human judgment. citeturn13view1turn13view2turn13view7turn14view14

Across the services, these mechanisms are appearing through the Department of the Air Force’s DAF Battle Network and Advanced Battle Management System lineage, the Navy’s Project Overmatch, the Army’s Project Convergence and Next Generation Command and Control, the Marine Corps’ Project Dynamis and Force Design, and the Space Force’s Proliferated Warfighter Space Architecture, overhead persistent infrared enterprise, satellite communications, and positioning, navigation, and timing capabilities. These are not five independent replacements for JADC2. They are service-specific implementations that must converge at agreed interfaces, data models, security controls, and command procedures. citeturn14view0turn14view2turn14view4turn14view6turn14view8

Space is indispensable to a global kill web because it supplies wide-area warning, tracking, communications relay, timing, navigation, and global reach. The emerging architecture is deliberately layered: GEO and highly elliptical systems provide persistence and strategic warning; proliferated LEO systems add lower-latency tracking, transport, tactical access, and resilience through numbers; MEO and other layers can provide additional warning, tracking, communications, and PNT functions. The Space Development Agency states that its LEO Tracking Layer is intended to send mission data directly over tactical data links, while its Transport Layer is designed as a low-latency optical-and-radio-frequency mesh. Nevertheless, GAO has warned that these outcomes depend on successful demonstration of laser communications, constellation integration, ground processing, and realistic delivery schedules. citeturn14view9turn13view6turn14view13

The principal analytical conclusion is therefore:

A kill web enables JADC2 not by creating one universal network, but by making mission threads composable across many networks, data environments, authorities, and domains—and by allowing those threads to degrade gracefully rather than fail at a single broken link.

From a linear kill chain to a resilient kill web

The traditional kill chain remains useful as a process model. Commanders still must locate an object or formation, establish its identity and position, maintain custody, determine whether it is a valid target, select an authorized effect, execute, and assess the result. Kill-web concepts do not abolish these obligations. Positive identification, collateral-risk analysis, rules of engagement, airspace and fires coordination, commander’s intent, and legal review remain applicable. Joint targeting education continues to teach F2T2EA for dynamic and time-sensitive targets. citeturn16search1turn16search10

The weakness arises when the process model is implemented as a fixed technical chain:

\[ Sensor_A \rightarrow Gateway_A \rightarrow Headquarters_A \rightarrow Shooter_A \]

In that arrangement, the loss of any essential node may force the targeting process to restart. A radar might have detected and fixed a target, but if its proprietary track cannot be consumed by another service’s fire-control system, the information may have to be manually re-entered or reacquired. If the headquarters responsible for weapon assignment becomes isolated, an otherwise capable shooter may wait for authority. If the original sensor is destroyed after transmitting an initial location, track custody may be lost when the target moves.

A kill web instead represents the mission as a graph:

\[ \{Sensors\} \leftrightarrow \{Fusion\ and\ Data\ Services\} \leftrightarrow \{Authorized\ C2\ Nodes\} \leftrightarrow \{Effects\} \]

The graph may contain preferred paths, but it also contains alternates. A node can be a platform, headquarters, software application, human decision-maker, coalition partner, satellite, or data service. An edge can be a radio link, satellite relay, optical crosslink, tactical data link, terrestrial network, machine-to-machine interface, or even a voice procedure used as a low-bandwidth fallback.

flowchart LR
    subgraph Sensors
        SP[Space warning and tracking]
        AIR[Airborne active and passive sensing]
        SEA[Ship and maritime sensors]
        LAND[Army and Marine ground sensors]
        ALLY[Coalition sensors]
    end

    subgraph Edge
        EP[Local processing]
        TAG[Time, confidence, provenance,\nclassification and releasability tags]
    end

    subgraph JADC2_Data
        FAB[(Federated data fabric)]
        BUS[Publish-subscribe messaging\nand tactical gateways]
        COP[Role-tailored common\noperating pictures]
        AI[Decision-support services]
    end

    subgraph Command
        AUTH[Authorized commander or delegate]
        ROE[Rules, control measures,\nweapons status and risk]
    end

    subgraph Effects
        AF[Air effect]
        NV[Maritime effect]
        AR[Land effect]
        MC[Expeditionary effect]
        NK[Cyber, electromagnetic or\nother non-kinetic effect]
    end

    SP --> EP
    AIR --> EP
    SEA --> EP
    LAND --> EP
    ALLY --> EP
    EP --> TAG --> FAB
    FAB <--> BUS
    FAB --> COP
    FAB --> AI
    AI --> AUTH
    COP --> AUTH
    ROE --> AUTH
    AUTH --> BUS
    BUS --> AF
    BUS --> NV
    BUS --> AR
    BUS --> MC
    BUS --> NK
    AF --> FAB
    NV --> FAB
    AR --> FAB
    MC --> FAB
    NK --> FAB

This architecture reflects the JADC2 Strategy’s emphasis on standardized interfaces, metadata tagging, common data-access practices, security, resilience in degraded electromagnetic environments, AI-enabled decision support, and worldwide transport with sufficient speed and bandwidth. It also reflects the DoD Data Strategy’s requirement that systems use open data standards and make data visible, accessible, understandable, linked, trustworthy, interoperable, and secure. citeturn13view0turn13view1turn13view2

The distinction between connectivity and command

The kill web should not be confused with an automatic “sensor sees, weapon fires” mechanism. Connectivity produces potential kill paths. Command structures determine which paths may be used.

A robust design therefore separates at least four functions:

RAND’s JADC2 framework similarly divides the problem into the C2 construct—including organization and where authorities reside—the data and infrastructure, and the tools and algorithms. The JADC2 Strategy calls for predetermined and, where appropriate, preapproved bundles of authorities to support rapid decisions from strategic levels to the tactical edge. This supports decentralization, but only within explicitly delegated bounds. citeturn14view14turn13view1

That distinction is essential during communications degradation. A disconnected unit may have excellent track data but insufficient authority to engage. Conversely, it may possess delegated authority but no longer have sufficiently current or reliable target data. Kill-web software should expose both conditions rather than treating connectivity as permission.

How the services contribute to a joint kill web

JADC2 succeeds only if service architectures act as interoperable parts of a joint system of systems. Each service enters the problem from a different operational perspective, which is both an advantage and a source of integration risk.

Department of the Air Force

The Department of the Air Force’s contribution centers on connecting sensing, battle management, command, and effects over large distances. The Program Executive Office for Command, Control, Communications and Battle Management describes the DAF Battle Network as connecting sensors, effectors, and logistics systems to improve situational awareness and decisions. The Air Force also established an integrated program office for the Joint Fires Network, described as fusing high-quality targeting data with C2 applications and supporting machine-to-machine targeting while retaining flexibility for tactical commanders. citeturn14view0turn14view1

The Air Force’s Open Mission Systems and Universal Command and Control Interface work illustrates the enabling role of open interfaces. AFRL describes UCI as a set of machine-to-machine mission-level C2 messages for airborne systems, while OMS seeks a nonproprietary mission-system architecture supporting technology insertion, service reuse, competition, and interoperability. These standards do not by themselves create a joint kill web, but they reduce the cost and time required to make aircraft, payloads, applications, and gateways exchange mission data. citeturn17view0turn17view1

The human component remains central. Air battle managers, air operations centers, airborne C2 elements, and tactical mission commanders interpret the operational context that an algorithm cannot fully infer from track geometry alone. The architecture must therefore support rapid machine-to-machine exchange without creating a presumption that every machine-generated recommendation is authoritative.

U.S. Navy

Project Overmatch is the Navy’s principal contribution to JADC2. The Navy describes it as developing networks, infrastructure, data architectures, and analytic tools to connect distributed manned and unmanned forces and enable synchronized effects from multiple directions and domains. Its operational context is Distributed Maritime Operations, in which ships, aircraft, submarines, unmanned systems, and shore elements may be widely separated and intermittently connected. citeturn14view4

For a naval kill web, the essential technical problem is not continuous high-bandwidth connectivity to every platform. It is maintaining enough trusted information for distributed forces to continue operating under emission control, jamming, cyberattack, or satellite disruption. That favors local processing, compact track messages, mission-type orders, selective synchronization, and alternative paths rather than dependence on constant raw-data streaming.

Coalition integration is particularly important because maritime operations routinely involve allied task groups. In 2025, Project Overmatch established a formal arrangement with the Five Eyes partners to embed personnel and collaborate on interoperable technologies. The Navy identifies Overmatch as its JADC2 contribution and states that it is integrating with the Joint Fires Network, other services, and coalition partners. citeturn14view5

U.S. Army

The Army uses Project Convergence as an experimentation and integration campaign and is fielding Next Generation Command and Control as a data-centric C2 architecture. Recent Army reporting describes a common data layer supporting resilient transport, edge computing, third-party applications, and AI models. Army budget material describes an integrated data layer with common core services, standardized access across warfighting-function applications, open architecture, and a Tactical Assault Kit foundation for portions of dismounted situational awareness and C2. citeturn14view2turn14view3turn17view2

This is particularly relevant to a kill web because land forces possess many heterogeneous sensors and fire-support systems deployed in difficult radio-frequency conditions. A division may need to combine air-defense radar data, unmanned-aircraft observations, electronic-support reports, intelligence products, friendly-force locations, airspace measures, and ammunition states. A common data layer can prevent every application from having to establish a unique interface to every source.

Army experimentation has also demonstrated the organizational nature of convergence. A Joint Force Quarterly account of Project Convergence described an F-35B initially unable to communicate with ground forces but subsequently integrated as both a sensor for ground shooters and a shooter supported by ground observers. The lesson is less about one platform pairing than about the repeatable integration process: expose data, translate semantics, validate quality, resolve authorities, and exercise the mission thread. citeturn18search4turn18search20

U.S. Marine Corps

Marine formations are designed to contribute forward sensors and effects while operating dispersed and under threat. The Marine Corps states that G/ATOR supports air defense, counterfire, and air traffic control and feeds joint kill webs. It describes NMESIS as integrated into naval and joint C2 and targeting architectures. citeturn14view7

Project Dynamis, formally established in 2025, is intended to accelerate Marine Corps contributions to combined JADC2 in partnership with Project Overmatch. Its stated focus is end-to-end joint interoperability, fused data, AI-supported decision advantage at the tactical edge, and communication of weapons-quality information. The initiative also established senior governance for responsibilities and authorities, recognizing that technical connectivity alone cannot resolve institutional ownership. citeturn14view6

The Marine operational contribution is therefore twofold. First, expeditionary forces can provide sensing from terrain or positions unavailable to larger platforms. Second, they can act as alternate engagement nodes when naval or air platforms are unavailable. Their vulnerability and limited bandwidth make edge autonomy, low-probability-of-intercept communications, compact data products, and mission command especially important.

U.S. Space Force

The Space Force supplies the global layer: missile warning and tracking, satellite communications, environmental awareness, PNT, and data transport. SDA describes the PWSA as a layered architecture containing Transport, Battle Management, Tracking, Custody, Navigation, and Support functions. The Transport Layer is intended to provide resilient, low-latency worldwide connectivity; the Tracking Layer provides warning and tracking of advanced missiles; the Custody Layer is intended to maintain awareness of time-sensitive mobile surface targets; and the Navigation Layer is intended to offer alternative PNT in GPS-denied conditions. citeturn14view8turn14view12

Space capabilities make geographically separated service architectures part of a global graph. Their value is not confined to initial detection. Satellites can cue terrestrial sensors, relay data among theaters, provide time synchronization, maintain custody beyond the horizon of one sensor, and distribute updates directly to tactical nodes.

Technical architecture and operating mechanisms

Common data standards and semantic interoperability

The hardest interoperability problem is often not transporting bits; it is ensuring that receiving systems interpret those bits identically.

A usable kill-web track should include more than latitude, longitude, and an identifier. Depending on mission and classification, its data object should carry:

• observation and update time;
• coordinate reference and datum;
• position, velocity, and associated uncertainty;
• track identity and correlation history;
• sensor type or protected source descriptor;
• confidence and quality;
• target classification and behavioral indicators;
• provenance and transformations applied;
• classification, releasability, and handling markings;
• validity period or expiration;
• relationship to command measures and no-strike or restricted entities.

The JADC2 Strategy calls for minimum metadata criteria, standardized data interfaces, common data-access practices, security standards, and continued application of the VAULTIS data goals. The DoD Data Strategy similarly calls for machine-readable data, standardized semantic meaning, rapid mediation of differing formats, immutable handling metadata, attribute-based access, and auditing. citeturn13view1turn13view3

The practical implication is that JADC2 cannot rely on a single universal message format. Legacy tactical data links, intelligence formats, service-native messages, APIs, imagery standards, and commercial cloud interfaces will coexist. The more realistic goal is a governed translation environment in which mappings, authoritative vocabularies, schemas, and quality rules are centrally governed but executed across distributed gateways.

Common operating pictures

A common operating picture should not mean that every participant sees an identical screen. A fighter aircraft, air-defense battery, carrier strike group, joint headquarters, and coalition liaison have different information needs and security permissions.

The underlying fabric should support multiple role-tailored views of a common data foundation:

• a tactical shooter may receive only the track, uncertainty, engagement status, and relevant control measures;
• an intelligence analyst may receive source history, competing hypotheses, and confidence decomposition;
• a commander may receive aggregate force disposition, risk, readiness, and decision points;
• a coalition partner may receive a releasable representation with sensitive sources removed;
• an automated application may consume machine-readable events without any graphical display.

RAND identifies the common operating picture and operational assessment as cross-cutting JADC2 processes, and the Army describes its common data layer as supporting a real-time operational view across sensors, fires, and airspace functions. citeturn13view7turn14view2

A COP is thus an output of the data fabric, not the fabric itself. Treating the display as the integration layer recreates brittle, application-specific stovepipes.

Data fabrics and messaging buses

A data fabric is the combination of data discovery, access, mediation, governance, synchronization, storage, and security services that lets distributed users treat data as an enterprise resource. It does not imply that all data resides in one cloud or one database. DoD’s own discussions of JADC2 emphasize common data fabrics, APIs, open-system data architecture, access management, standards, and security. citeturn17view5

A messaging bus carries events or state changes among producers and consumers. For kill-web purposes, a data-centric publish-subscribe pattern is attractive:

• sensors publish observations or track updates;
• fusion applications subscribe to relevant categories;
• commanders and decision aids subscribe to changes affecting their mission;
• shooters receive only authorized, mission-relevant updates;
• assessment data returns to the same ecosystem.

This decouples the producer from the consumer. A sensor need not know every future shooter; it publishes to an agreed semantic and security contract. UCI is one official example of standardized machine-to-machine mission messages in the airborne domain. Commercial implementations such as Data Distribution Service illustrate a publish-subscribe pattern, but no single commercial bus should be treated as the universal JADC2 solution. citeturn17view0turn17view4

In disconnected, intermittent, and limited-bandwidth environments, the bus must support local persistence, message prioritization, expiration, deduplication, store-and-forward behavior, and eventual synchronization. An industry whitepaper on DIL-tailored data fabrics recommends local processing, lazy transfer, node independence, bandwidth prioritization, and decentralized control. These are industry recommendations rather than DoD-mandated architecture, but they align with the operational requirements of dispersed kill webs. citeturn17view3

Latency and throughput

Kill-web latency should be decomposed rather than expressed as one marketing number:

\[ T_{mission} = T_{sense} + T_{process} + T_{transport} + T_{fusion} + T_{decision} + T_{authorization} + T_{effect} \]

Reducing transport delay is useful, but a fast network cannot compensate for slow correlation, ambiguous authority, poor target confidence, or a lengthy manual handoff. Conversely, a mission can succeed over a modest-bandwidth link if the edge node sends a compact, trusted track rather than raw imagery.

Throughput management should follow operational value. Priority traffic normally includes warning messages, track deltas, command acknowledgments, engagement status, PNT corrections, and network-health information. Raw full-motion video, large imagery products, and historical data may be processed or cached locally unless specifically requested.

Orbital physics provides useful lower bounds, though not real system performance. For an idealized satellite at 1,000 kilometers altitude, a straight ground-to-satellite-to-ground path of 2,000 kilometers has a free-space propagation time of approximately 6.7 milliseconds. For GEO at 35,786 kilometers altitude, the corresponding idealized ground-satellite-ground path is approximately 239 milliseconds one way, or about 477 milliseconds round trip, before processing, routing, atmospheric, queuing, and geometric effects. Actual paths are longer and operational latency may be substantially higher. citeturn15calculator0turn15calculator1turn15calculator2

This explains—but does not by itself guarantee—the attraction of LEO transport for time-sensitive tactical traffic. SDA describes its Transport Layer as an optical-and-RF mesh designed for low-latency sensor-to-shooter connectivity and direct tactical communications. citeturn13view6

Security and zero trust

A kill web enlarges the attack surface. More interfaces, automated transactions, coalition gateways, and remotely updated software create more opportunities for identity theft, malicious data injection, compromised applications, supply-chain attack, and denial of service.

The DoD Zero Trust Strategy rejects implicit trust based solely on network location. It organizes security around seven pillars and calls for continuous verification, least privilege, trusted and tagged data, and access decisions based on identity, device, application, environment, and data attributes. It also expressly links zero trust to coalition interoperability and the secure sharing of actionable data. citeturn13view4turn13view5

For a kill web, zero trust should be implemented at the data and transaction level, not merely at login:

Security creates its own latency and availability tradeoffs. Excessively centralized identity or policy services can become single points of failure. Tactical nodes therefore need cached credentials, locally enforceable policy, bounded offline authority, and secure re-synchronization—without turning disconnected operation into permanent implicit trust.

Coalition interoperability

Coalition interoperability has technical, semantic, security, procedural, and political dimensions. Even when partners use a common tactical data link, they may differ in track naming, classification rules, cryptography, target-validation standards, or delegated authorities.

NATO’s Federated Mission Networking model is relevant because it treats interoperability as a governed federation of national and NATO capabilities rather than one monolithic network. Its framework combines people, processes, standards, architectures, and mission networks and emphasizes reuse of existing capabilities. citeturn14view15

A coalition kill web therefore needs:

• releasability encoded with the data rather than handled only through manual review;
• cross-domain solutions and sanitization services;
• agreed track-quality and coordinate standards;
• partner identity and credential federation;
• preplanned fallback procedures;
• shared terminology for weapons status, target confidence, and engagement authority;
• auditable national caveats.

Not every partner should receive every sensor source or algorithmic explanation. The objective is to provide the minimum trusted information needed for coordinated action while protecting sensitive methods.

Decision-support automation

Automation is most valuable where the number of possible kill paths exceeds what a human staff can compare in the available time. An application can continuously evaluate:

\[ Utility(path)= MissionEffect \times TrackConfidence \times Authorization \times CommunicationsProbability \times WeaponAvailability - Risk \]

Possible functions include track correlation, sensor-tasking recommendations, route selection, bandwidth allocation, course-of-action generation, weapon-target pairing, collateral-risk screening, and prediction of when a track will fall below engagement quality.

The JADC2 Implementation Plan describes automation, AI, predictive analytics, and machine learning as tools for sensing, making sense, and acting. RAND nevertheless emphasizes that algorithms must be developed together with policy, training, doctrine, infrastructure, and command structures. Air University analysis likewise cautions that technology should support practiced operational kill paths rather than drive them. citeturn17view6turn14view14turn18search28

Automation should therefore produce recommendations with explanations and confidence, not opaque answers. A commander needs to know why a route was selected, which assumptions dominate, what data are stale, and what event would trigger an abort.

Tabletop scenario: a kill web defeats a linear kill chain

Scenario design

The following scenario is synthetic and uses only unclassified, generic representations of capabilities. All timings are illustrative tabletop assumptions, not claimed performance figures for actual systems. Specific frequencies, ranges, vulnerabilities, weapon parameters, and classified tactics are deliberately omitted.

Operational setting. A joint and coalition force is protecting an island logistics hub and a maritime reinforcement corridor. “Red” operates a mobile coastal missile unit, unmanned reconnaissance aircraft, electronic-attack systems, and a surface combatant. Red’s intent is to launch a coordinated missile attack and then relocate the mobile launcher before Blue can respond.

Blue forces. The force includes:

• USSF overhead warning and LEO transport/tracking services;
• a Navy surface combatant and airborne maritime C2 aircraft;
• an Air Force passive-sensing aircraft and airborne battle-management element;
• an Army integrated air-defense unit, a mobile C2/data-layer node, and a long-range effects unit;
• a Marine littoral unit with G/ATOR-like sensing and expeditionary fires;
• a coalition coastal radar and command node;
• cyber/electromagnetic support teams;
• a joint task force headquarters with predetermined authority matrices.

Official sources describe G/ATOR as feeding joint kill webs, the DAF Battle Network as connecting sensors and effectors, the Army’s NGC2 data layer as integrating sensors and fires, Project Overmatch as connecting distributed naval forces, and SDA’s architecture as providing low-latency transport and missile tracking. citeturn14view7turn14view1turn14view2turn14view4turn14view8

Pre-exercise authority and data conditions

Before the crisis, the joint force commander establishes:

The data fabric requires every observation to include time, uncertainty, provenance, releasability, and sensor-health indicators. Each effect request includes the authorizing commander, rule set, target identifier, expiration time, and acknowledgment requirement.

Step-by-step timeline

Rerouting logic for the tabletop

A practical exercise controller can model each candidate route with six variables:

\[ RouteScore = F \times Q \times A \times C \times S \times R \]

where:

• \(F\) = freshness of the information;
• \(Q\) = track quality and source diversity;
• \(A\) = availability of required command authority;
• \(C\) = probability of successful communications;
• \(S\) = suitability and availability of the proposed effect;
• \(R\) = releasability to every participant in the path.

A zero in any mandatory factor invalidates the route. For example, a high-quality track with no engagement authority is not a valid firing path; an authorized shooter receiving stale data is likewise invalid.

The controller should inject failures at five levels:

Key decision nodes

The scenario’s value lies less in the precise timestamps than in forcing staffs to answer six questions:

Track sufficiency: Is the object merely detected, continuously tracked, or supported by data sufficient for the proposed effect?

Identity and attribution: Which observations support the classification? Are they independent, or are several systems repeating the same original source?

Authority: Who may approve defensive action, nonlethal effects, or deliberate strike? Does that authority remain valid during isolation?

Path selection: Which combination of sensor, command node, transport, and effect is most robust—not merely fastest?

Abort and reassessment: Which new event causes an automatic hold, human review, rerouting, or termination?

Assessment: What evidence is sufficient to conclude the desired effect was achieved, and who decides whether another engagement is required?

Kill chain versus kill web

Marine doctrine’s description of multiple sensor-and-shooter combinations directly supports the resilience distinction. DARPA’s kill-web work emphasizes rapid cross-organizational tasking and retasking, while the JADC2 Strategy and RAND research emphasize data, resilient infrastructure, authorities, and decision-support tools. citeturn16search2turn18search11turn13view0turn14view14

Space architecture for a global kill web

Why multiple orbital regimes are required

No single orbit optimizes persistence, latency, coverage, revisit, survivability, payload size, and cost.

flowchart TB
    GEO[GEO OPIR and communications\nPersistent wide-area strategic view\nHigher propagation delay]
    HEO[HEO and polar sensing\nHigh-latitude persistence]
    MEO[MEO sensing, communications and PNT\nRegional or global intermediate layer]

    subgraph LEO[PWSA and other proliferated LEO systems]
        LT1[Tracking and custody satellites]
        LT2[Transport satellites]
        LT3[Optical inter-satellite crosslinks]
        LT4[Onboard processing and routing]
        LT1 <--> LT2
        LT2 <--> LT3
        LT3 <--> LT4
    end

    GND[OPIR and mission ground systems\nFORGE and other processing]
    GEP[Ground entry points and gateways]
    TAC[Aircraft, ships, ground formations\nand tactical weapons]
    C2[Joint and coalition C2/data fabrics]
    GPS[GPS and alternative PNT sources]

    GEO --> GND
    HEO --> GND
    MEO --> GND
    GEO -. cue and warning .-> LEO
    HEO -. cue and warning .-> LEO
    LEO --> GEP
    LEO -->|Direct tactical data link where equipped| TAC
    GEP <--> C2
    C2 <--> TAC
    GPS --> LEO
    GPS --> TAC
    LEO -->|Alternative navigation and timing support| TAC
    TAC -->|Observations, tasking and assessment| LEO

GAO’s public depiction distinguishes LEO, MEO, and GEO and notes that proliferated architectures can lose an individual satellite with a smaller reduction in total capability than architectures built around a few satellites. citeturn13view8

GEO provides persistent viewing of large areas and is well suited to strategic missile warning and communications coverage. Its limitations include long propagation paths, high-value concentration, and reduced geometry at high latitudes.

HEO offers long dwell over polar and high-latitude regions that GEO observes poorly. The Space Force’s SBIRS architecture includes both GEO satellites and HEO-hosted sensors. citeturn14view10

LEO offers shorter propagation paths, stronger received signals for a given terminal design, and closer-range sensing, but each satellite sees a smaller area and moves rapidly relative to users. Continuous service therefore requires a constellation, frequent handovers, robust routing, and many ground or crosslink connections.

MEO occupies an intermediate regime and can support PNT, communications, and missile-warning or tracking architectures. Space Force’s FORGE enterprise is intended to integrate data from legacy SBIRS, Next-Gen OPIR GEO and polar systems, and MEO and LEO constellations. citeturn14view11

Persistent strategic warning versus tactical tracking

Traditional overhead persistent infrared systems focus heavily on detecting launch signatures and providing strategic or theater warning. SBIRS combines GEO and HEO sensors and worldwide ground systems. citeturn14view10

A tactical kill web requires more than a launch alert. It needs sufficiently frequent updates, uncertainty estimates, and track continuity to cue defenses and, for demanding missions, support engagement-quality solutions. Proliferated LEO tracking architectures seek to observe dimmer and more maneuverable threats from closer range and from multiple viewing geometries.

SDA describes its Tracking Layer as a global infrared constellation integrated with low-latency communications. In a July 2026 award announcement, SDA stated that Tracking Layer satellites would provide mission data directly over tactical data links from LEO. This is a significant architectural shift: instead of requiring all space data to pass through a distant strategic processing center before reaching a tactical user, selected products can be processed, routed, and delivered closer to the engagement timeline. citeturn14view9

This does not imply that raw satellite measurements should flow directly into a weapon without validation. Tactical dissemination must still address track quality, coordinate conversion, latency, authentication, source correlation, command authority, and weapon-system certification.

Crosslinking and space-based routing

Without crosslinks, a LEO satellite can normally send data only when it is simultaneously in view of a suitable ground station or user terminal. Optical inter-satellite links allow data to move across the constellation toward a satellite with access to the appropriate destination.

SDA describes the Transport Layer as a globally accessible mesh using optical and RF links. Its architecture is intended to route data from any connected source toward connected destinations, including ground entry points, space mission partners, and appropriately equipped air, maritime, and land platforms. citeturn13view6

In kill-web terms, crosslinks turn a collection of satellites into a spaceborne network layer. They can:

• forward a missile-track update toward the theater rather than waiting for a local ground-station pass;
• relay sensor tasking to another satellite;
• route around a failed or unavailable spacecraft;
• distribute a common time-sensitive event to multiple theaters;
• reduce dependence on long terrestrial backhaul paths.

The challenge is that optical links require accurate pointing, acquisition, tracking, interoperability among vendors, network management, and reliable operation across moving satellites. GAO reported that the Tracking Layer depends on functional Transport Layer satellites and noted that some laser-communications capabilities had not been fully demonstrated before follow-on contracts were awarded. citeturn14view13

Downlink and edge processing

A global sensing architecture can produce more data than tactical networks can carry. The solution is a hierarchy of processing:

1. On-sensor processing detects events, filters noise, compresses data, and generates candidate tracks.
2. On-orbit or nearby fusion correlates observations where feasible and prioritizes urgent products.
3. Ground mission processing performs more computationally intensive correlation, exploitation, calibration, intelligence analysis, and long-term storage.
4. Theater edge services translate data into joint and tactical formats, apply releasability rules, and fuse it with terrestrial sources.
5. Tactical nodes receive only mission-relevant tracks, cues, warnings, timing data, or selected imagery.

This hierarchy reduces bandwidth demand and delay but places greater responsibility on software running in orbit and at the edge. Algorithms must be updateable, testable, cyber-resilient, and traceable. False positives or calibration errors propagated at machine speed could affect many downstream users.

The ideal relationship is not “space replaces terrestrial sensors.” Space provides early warning, broad-area custody, and beyond-line-of-sight connectivity; terrestrial sensors provide complementary geometry, higher local resolution, target discrimination, and independent confirmation.

Positioning, navigation, and timing

PNT is a hidden dependency in almost every kill-web transaction. Sensors need accurate time to correlate observations. Platforms need navigation to report their own position. Networks need synchronization. Effects require consistent coordinate and timing references.

GPS remains a principal source, but a resilient architecture requires alternatives and cross-checks. SDA states that its Navigation Layer is intended to establish GPS-independent navigation for PWSA using optical inter-satellite ranging and optical space-to-ground links. citeturn14view12

A kill web should treat PNT as a data object with quality indicators rather than an invisible constant. Each track or firing solution should be traceable to its time and coordinate sources, their estimated error, and whether they agree with alternatives. During spoofing or jamming, the system may continue operating at reduced precision, shift to inertial or terrestrial references, or inhibit effects whose accuracy requirements cannot be met.

Direct LEO-to-tactical feeds

Direct delivery from LEO to tactical platforms can eliminate several serial steps:

\[ Satellite \rightarrow Strategic\ Ground\ Site \rightarrow Enterprise\ Network \rightarrow Theater\ Gateway \rightarrow Tactical\ User \]

becomes, for selected messages:

\[ Satellite \rightarrow Tactical\ Data\ Link \rightarrow Tactical\ User \]

SDA has demonstrated Link 16 connectivity from LEO to terrestrial users and describes tactical satellite communications and direct-to-platform connectivity as Transport Layer objectives. Its 2026 Tracking Layer announcement states that mission data will be distributed directly over tactical data links. citeturn13view6turn14view9

The operational advantages are lower path length, fewer gateway dependencies, and faster warning or track updates. The engineering and command challenges include:

• terminal field of view and antenna constraints;
• waveform and cryptographic compatibility;
• satellite handovers;
• congestion and time-slot management;
• assurance that the tactical recipient understands space-derived track quality;
• certification for use in fire-control functions;
• deconfliction between tactical and strategic priorities;
• emissions and signature-management concerns.

Direct feed should therefore be viewed as an additional edge in the web, not a mandatory replacement for ground processing or command oversight.

Space-specific failure modes

The layered architecture reduces dependence on a single system, but it also creates system-of-systems integration risk. GAO’s assessment emphasizes that Tracking, Transport, ground systems, laser communications, and multiple contractors must operate together for the intended missile-warning and tracking mission to succeed. citeturn14view13

Findings, risks, and design principles

The kill web is primarily an architecture of choices

The metric that matters is not the number of connected platforms. It is the number of valid, authorized, survivable mission paths available at a particular time.

A network may contain thousands of nodes yet offer only one legal and technically usable route to a target. Conversely, a modest network may be highly resilient if it has diverse sensors, independent communications, delegated authority, open interfaces, and well-rehearsed fallback procedures.

Useful readiness measures would therefore include:

Decentralization must be designed, not improvised

Faster communications do not automatically produce faster decisions. If every tactical choice still requires approval from a distant headquarters, the network can merely deliver indecision more quickly.

JADC2’s human-enterprise line of effort recognizes the need for doctrine, training, organizational adaptation, and preapproved or event-driven authorities. RAND likewise identifies authority location and organizational design as primary JADC2 enablers. citeturn13view1turn14view14

Effective decentralization requires:

• clear commander’s intent;
• explicit decision rights;
• machine-readable but human-understandable rules;
• thresholds for local action;
• expiration of delegated authority;
• reporting and audit obligations;
• regular exercises under network loss.

The correct degree of delegation differs among strategic warning, defensive fires, deliberate strike, cyber effects, and nuclear command and control. JADC2 should support these distinctions rather than flattening them.

Resilience requires heterogeneity and graceful degradation

A web built from many identical nodes sharing one software stack, waveform, cloud provider, or PNT source may appear distributed while remaining vulnerable to common-mode failure. Resilience requires diversity across sensing modalities, orbital layers, communications media, vendors, software components, locations, and command posts.

Graceful degradation also requires explicit quality states. A track should not remain marked “weapons quality” merely because the display still shows a symbol after its primary sensors disappear. The system must visibly reduce confidence, expand uncertainty, and inhibit actions when required.

Data provenance is both an operational and accountability requirement

Multi-source fusion can improve target attribution, but only if the system knows whether reports are independent. Five displays may all repeat one original sensor. Without provenance, apparent corroboration can be illusory.

Every transformation should therefore preserve a chain of custody:

\[ Observation \rightarrow Translation \rightarrow Correlation \rightarrow Human\ Approval \rightarrow Effect \rightarrow Assessment \]

DoD data-security objectives call for immutable handling metadata and full auditing, while zero-trust principles require continuous verification and least-privilege access. citeturn13view3turn13view4

This record supports operational reconstruction, legal review, cyber defense, model improvement, and determination of who made each decision. It is especially important when an engagement draws on several services and coalition sources.

AI should optimize within constraints, not invent authority

Decision-support automation is suited to comparing routes, identifying sensor gaps, predicting track loss, prioritizing bandwidth, and generating courses of action. It is less suited to resolving political intent, legal ambiguity, escalation risk, or unclear commander’s intent.

The safest model is constraint-bounded optimization:

1. humans establish objectives, prohibited outcomes, authorities, and risk limits;
2. software searches for technically feasible paths;
3. the system explains confidence, sources, assumptions, and alternatives;
4. an authorized human approves, modifies, or rejects consequential action;
5. execution and assessment are logged and fed back into the model.

The initial CJADC2 capability delivered in 2024 combined software applications, data integration, and cross-domain concepts as a minimum viable capability, illustrating that JADC2 is being fielded incrementally rather than as a single completed global system. citeturn17view7

Coalition interoperability should be an initial condition

Retrofitting releasability and partner access after a U.S.-only architecture is built creates delays, manual workarounds, and duplicated pictures. The Project Overmatch Five Eyes arrangement and NATO Federated Mission Networking both point toward continuous coalition involvement in standards, governance, testing, and personnel exchanges. citeturn14view5turn14view15

A combined kill web should be exercised from the outset with realistic national caveats, classification boundaries, degraded links, different weapons-release authorities, and partner-owned sensors. Technical success in a U.S.-only demonstration is not sufficient evidence of combined operational capability.

The space layer is powerful but not self-sufficient

Proliferated LEO architectures can shorten paths, add resilience, and bring space data closer to tactical users. GEO and HEO remain valuable for persistent warning and regional coverage. Ground and airborne sensing remain necessary for discrimination, local geometry, and redundancy.

The correct design is a layered, hybrid architecture in which space, air, maritime, land, cyber, commercial, and coalition capabilities reinforce one another. PWSA’s transport, tracking, custody, battle-management, and navigation layers embody this direction, while FORGE is intended to integrate data across legacy and future OPIR constellations. citeturn14view8turn14view11

At the same time, GAO’s findings show why architectures should be evaluated through end-to-end mission threads rather than satellite counts. A tracking satellite that cannot reliably move its data through crosslinks, ground systems, tactical formats, security boundaries, and command processes does not close a kill web. citeturn14view13

Overall assessment

Kill webs enable JADC2 when they combine three forms of interoperability:

Technical interoperability allows systems to exchange and interpret data through standards, APIs, gateways, transport, and common security services.

Operational interoperability aligns common pictures, battle drills, target-quality criteria, engagement procedures, and fallback actions.

Institutional interoperability aligns command relationships, delegated authorities, acquisition governance, coalition agreements, training, and accountability.

Failure in any one dimension can invalidate an otherwise promising mission path. A perfectly connected shooter without authority cannot act; an authorized shooter with semantically ambiguous data should not act; a validated target and authorized shooter cannot act in time if the communications route is brittle.

The kill web’s decisive advantage over a linear chain is therefore not indiscriminate speed. It is controlled adaptability: the ability to preserve sensing, decision, and effect options as platforms are jammed, destroyed, disconnected, constrained by national caveats, or rendered unsuitable. JADC2 supplies the enterprise data, security, technical, human, and command foundations that make that adaptability repeatable across the Air Force, Navy, Army, Marine Corps, Space Force, and mission partners.