03 / Enterprise integration
Kill Webs as Mission Threads Through JADC2
A joint-enterprise route separating the broader JADC2 framework—data, networks, people, doctrine, authorities, security, partners, and training—from the narrower mission pathways that connect sensing, decision, support, and effects.
DIRECT ANSWER / EVIDENCE BOUNDARY
Route in brief
- Central claim
- A kill web enables JADC2 only when a mission thread can cross service, domain, echelon, classification, and partner boundaries without losing meaning, authority, provenance, or graceful-degradation options.
- Evidence posture
- Cross-service synthesis with program maturity kept explicit
- Primary boundary
- JADC2 is not one product, one network, or one command application.
DEFINITION AND CENTRAL CLAIM
JADC2 is the enterprise; the kill web is one composable operational thread
A joint-enterprise route separating the broader JADC2 framework—data, networks, people, doctrine, authorities, security, partners, and training—from the narrower mission pathways that connect sensing, decision, support, and effects.
Central claim
A kill web enables JADC2 only when a mission thread can cross service, domain, echelon, classification, and partner boundaries without losing meaning, authority, provenance, or graceful-degradation options.
EVIDENCE-QUALIFIED SYNTHESIS
What the retained material supports
Labels distinguish documented public records, architectural synthesis, cautions, recommendations, and publicly unspecified details. A citation does not erase the qualification in the sentence.
SUPPORTED BY SUBMITTED REPORTS
The reports consistently frame JADC2 or CJADC2 as broader than targeting: it includes data, transport, analytics, command structures, policy, authorities, organizations, training, partners, and operational procedures. [12] [6] [1]
SUPPORTED BY SUBMITTED REPORTS
Service-specific initiatives contribute different sensing, transport, command, fires, maritime, expeditionary, and space capabilities, but joint value depends on agreed interfaces, semantics, identity, and operating procedures. [12] [6]
EVIDENCE CAUTION
A common operating picture should provide role-tailored views over consistent underlying data; identical screens for every user can be as misleading as incompatible pictures. [12]
SUPPORTED BY SUBMITTED REPORTS
Space-based warning, tracking, transport, communications, and positioning are described as critical enablers, while public reports also retain integration, schedule, ground-processing, and demonstration uncertainties. [12] [6]
RECOMMENDED CONTROL
Coalition integration requires explicit classification, releasability, provenance, identity, and policy controls; a technically reachable partner node is not automatically an authorized participant in every mission thread. [12] [6] [13]
RECOMMENDED CONTROL
Role-tailored common operating pictures should preserve one shared record identity, source time, uncertainty, authority, and assessment state even when each partner receives a different level of technical detail. [12] [6] [13]
PUBLIC-INTEREST IMPLICATIONS
What responsible institutions can do with this evidence
- Define mission-thread contracts that span data meaning, quality, authority, release, timing, and fallback behavior.
- Measure joint outcomes across services instead of counting isolated platform deliveries.
- Design role-tailored interfaces that preserve one underlying evidence and identity model.
- Exercise partner and classification boundaries before a crisis makes manual workarounds the default.
- Test the least-detailed authorized partner view as part of the mission thread, not as an after-the-fact dissemination product.
EVIDENCE CAUTIONS
What this route should not be used to claim
- JADC2 is not one product, one network, or one command application.
- Public program names and demonstrations do not establish enterprise-wide interoperability or operational maturity.
- Connecting selected assets is different from connecting every asset.
- The public route omits real classification rules, partner data, mission configurations, and operational dependencies.
OPEN QUESTIONS
Questions the current public record does not settle
An open question is not a prediction, a finding, or proof that a capability is fielded in the configuration described.
- Which joint mission outcomes should own funding and accountability across service portfolios?
- How can one evidence record support different role views without hiding material uncertainty?
- What is the minimum viable coalition data contract under contested and intermittent connectivity?
- How should a mission thread degrade when space, long-haul transport, or a classification gateway is unavailable?
RETAINED SOURCES
Selected records underlying this public synthesis
Submitted reports, official program descriptions, doctrine, policy, oversight, and public research are labeled separately. Inclusion is not blanket endorsement.
-
Submitted joint-integration analysis
Kill Webs as the Operational Engine of Joint All-Domain Command and Control
Submitted joint-integration report. It treats JADC2 as the broader enterprise and the kill web as a composable mission thread spanning data, transport, authorities, services, partners, and effects.
-
Submitted joint-integration analysis
The Algorithmic Battlespace: Architecting the Kill Web and the Future of Combined Joint All-Domain Command and Control
Submitted JADC2 integration report. It supplies service, space, coalition, data-fabric, and mission-thread framing; scenario details are treated as illustrative rather than operational fact.
-
Submitted architecture report
From Kill Chain to Kill Web: Operational Rationale, Technical Architecture, and the DARPA ACK Model
Submitted architecture report. It distinguishes documented public facts, architectural synthesis, and recommended engineering targets; this release preserves those distinctions and does not independently reverify every cited source.
-
Submitted comparative analysis
Kill Web vs. Kill Chain: From Sequential Targeting Processes to Composable Battle Networks
Submitted comparative report. It provides the collection’s clearest process-versus-topology distinction and cautions that connectivity, resilience, command authority, and lawful use are separate variables.
-
Submitted architecture report
The Architecture of Decision-Centric Warfare: Engineering the Transition from Kill Chains to Cross-Domain Kill Webs
Submitted engineering architecture report. It covers modular hardware, edge computing, transport, middleware, capability orchestration, and centralization risk at a conceptual level.