02 / Program analysis
DARPA ACK and the Capability-Marketplace Model
An evidence-bounded explanation of DARPA’s Adapting Cross-Domain Kill-Webs program, its consumer–supplier marketplace analogy, bid-and-offer logic, Virtual Liaison abstraction, and the public limits on what is known about transition and fielding.
DIRECT ANSWER / EVIDENCE BOUNDARY
Route in brief
- Central claim
- ACK addressed the decision and resource-composition problem: represent what organizations can provide, compare constrained combinations, and recommend alternative command-and-control plays without making the marketplace itself the authority to employ force.
- Evidence posture
- Public program description plus cross-report architectural interpretation
- Primary boundary
- Marketplace language is an analogy; military authority, risk, and legal review cannot be reduced to price.
DEFINITION AND CENTRAL CLAIM
Discover, compare, and reallocate capabilities across boundaries
An evidence-bounded explanation of DARPA’s Adapting Cross-Domain Kill-Webs program, its consumer–supplier marketplace analogy, bid-and-offer logic, Virtual Liaison abstraction, and the public limits on what is known about transition and fielding.
Central claim
ACK addressed the decision and resource-composition problem: represent what organizations can provide, compare constrained combinations, and recommend alternative command-and-control plays without making the marketplace itself the authority to employ force.
INTERACTIVE / SYNTHETIC / CONSTRAINT-FIRST
Capability Marketplace Lab: eligibility before comparison
This deterministic, client-local model uses fictional service packages to explain the public ACK idea of capability discovery, offers, constraints, and comparative recommendations. Hard gates remove ineligible packages before any score is calculated. [1] [8] [13] [11] [10]
All fictional dependencies are available. Hard gates still exclude packages whose evidence or independent assessment is incomplete.
Package Lantern
Shareable observation, edge interpretation, alternate relay, bounded response, and independent assessment.
Lower detail and slower refresh are explicit tradeoffs for release compatibility and independent resilience.
Shared dependencies
- Edge Fusion
- Alternate Relay
- Independent Assessment
- Authority Service
Package Harbor
High-detail observation, central fusion, primary relay, bounded response, and independent assessment.
High timeliness and capacity depend on central services and release approval.
Shared dependencies
- Central Fusion
- Primary Relay
- Independent Assessment
- Authority Service
Package Orchard
Open observation, central fusion, shared translator, open response service, and independent assessment.
The shared translator is reachable, but its provenance record is incomplete and it remains a common-mode dependency.
Shared dependencies
- Central Fusion
- Shared Translator
- Independent Assessment
- Authority Service
Package Ridge
Distributed observation, edge interpretation, store-and-forward relay, bounded response, and shared self-assessment.
The same service that recommends and executes would assess itself; independent assessment is not demonstrated.
Shared dependencies
- Edge Fusion
- Store Forward
- Shared Assessment
- Authority Service
Package Signal
Partner observation, regional fusion, alternate relay, bounded response, and independent assessment.
One provider identity and service-contract state cannot be authenticated, so connectivity does not establish eligibility.
Shared dependencies
- Regional Fusion
- Alternate Relay
- Independent Assessment
- Partner Identity
All names, packages, dependencies, conditions, values, and outcomes are fictional teaching constructs. They are not DARPA scoring rules, operational mission data, force packages, targeting guidance, or a representation of a fielded system.
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 describe ACK as adapting commercial marketplace, sourcing, and supply-chain ideas: mission demand appears as a consumer need, while organizations advertise available capabilities as suppliers. [1] [8]
SUPPORTED BY SUBMITTED REPORTS
The Virtual Liaison abstraction is presented as a way to expose an effect, availability, and constraints without necessarily disclosing every sensitive source, method, or internal implementation detail. [1] [8]
PUBLICLY UNSPECIFIED
The reports say ACK reduced some reallocation and assignment decisions to the order of minutes and transitioned technology to military Services, while the receiving programs, fielded configurations, and operational extent remain incompletely public. [1] [8]
CROSS-REPORT ANALYSIS
ACK and integration middleware solve different problems: orchestration selects a candidate combination; translation and gateway technologies make heterogeneous systems exchange usable data. [1] [7] [12]
RECOMMENDED CONTROL
Any marketplace recommendation must remain subordinate to identity, data quality, capacity, release, command authority, rules, safety, and consequence constraints enforced outside the optimization score. [1] [11]
RECOMMENDED CONTROL
A defensible marketplace evaluates hard eligibility before comparative utility: authority, identity, provenance, releasability, and assessment should be fail-closed gates, while timeliness, resilience, capacity, auditability, and reversibility may inform ranking among the remaining options. [1] [11] [13]
PUBLIC-INTEREST IMPLICATIONS
What responsible institutions can do with this evidence
- Publish capability descriptions with explicit quality, availability, latency, authority, and releasability metadata.
- Separate recommendation, authorization, reservation, execution, and assessment into auditable states.
- Use alternative-plan generation to surface tradeoffs rather than presenting one opaque optimum.
- Test how the marketplace behaves when suppliers withdraw, data becomes stale, or a shared dependency fails.
- Treat capability withdrawal, reservation, authorization, and outcome assessment as separate versioned events so one stale offer cannot remain silently executable.
EVIDENCE CAUTIONS
What this route should not be used to claim
- Marketplace language is an analogy; military authority, risk, and legal review cannot be reduced to price.
- A recommendation engine does not prove automated engagement authority.
- Public reports do not disclose the complete scoring functions, data schemas, cyber controls, or transition recipients.
- Minute-scale cross-domain allocation should not be conflated with local millisecond control loops.
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.
- How should capability offers represent uncertainty, hidden dependencies, and confidence decay?
- Who may override a recommended play, and what evidence must the override preserve?
- How can coalition suppliers advertise useful capability without overexposing sensitive information?
- What prevents a locally optimal assignment from creating enterprise-wide resource contention or escalation?
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 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 architecture report
From Kill Chain to Kill Web: Strategic Rationale, Technical Architecture, and DARPA’s ACK Program
Submitted executive architecture report. It is especially useful for the optionality argument, mission-specific timing, ACK boundaries, and unresolved public parameters.
-
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.
-
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 AI and autonomy analysis
AI and Autonomy in Kill Webs
Submitted AI decision-support report. It argues for uncertainty and provenance preservation, independent constraint gates, abstention, realistic human-machine testing, and bounded autonomy.
-
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.