What MDTFs are built to do—and what that assumes about communications
The Multi-Domain Task Force is the Army's formation concept for large-scale combat operations against a peer adversary with advanced anti-access and area-denial capabilities. An MDTF integrates long-range precision fires, space and cyber effects, electronic warfare, and intelligence functions—the Intelligence, Information, Cyber, Electronic Warfare, and Space (I2CEWS) construct—precisely because those effects need to be coordinated faster than the traditional echelonment of capabilities allows. [The foundational operational concept is TRADOC Pamphlet 525-3-1, *The U.S. Army in Multi-Domain Operations 2028*, available through army.mil/tradoc.]
The paradigmatic MDTF scenario is the Pacific. An adversary with advanced anti-satellite weapons, ground-based electronic warfare systems, and cyber capabilities can contest every communications layer simultaneously—satellite uplinks, radio frequency links to forward positions, fiber cables. The MDTF design assumes this. The formation is not designed to wait for a connectivity window before engaging a target; it is designed to sustain combat operations through contested communications.
That assumption has an immediate technical consequence: every C3 architecture that feeds into an MDTF operation needs a specified plan for what it does when connectivity disappears. Not a graceful error message—a continued capability. Programs that do not specify this have, in effect, designed for a different formation.
How the kill chain's data transport requirements actually break down
The joint targeting cycle—find, fix, track, target, engage, assess—has distinct network dependencies at each phase, and not all of them are equally sensitive to communications denial.
Find and fix. Correlation of multiple sensor feeds into a tentative target location benefits from wide-area network access, but the most time-sensitive elements are local. An organic sensor reporting to the processing node it is physically connected to does not require wide-area connectivity. Pre-positioned fusion models and correlation rules allow a local node to process its own data without reaching back. This phase is more tolerant of denial than it appears if the architecture is designed correctly.
Track. Continuous or near-continuous updates to a target location sufficient to produce a firing solution. For a long-range precision fires mission—a PrSM engagement at several hundred kilometers—tracking quality requirements are demanding and time-critical. High-value relocatable targets move. An MDTF targeting a relocatable launcher cannot tolerate tracking gaps measured in minutes. This is the kill chain step most sensitive to communications denial, and the step where most current JADC2 program specifications are least precise about zero-connectivity performance.
Target and engage. A completed targeting packet, engagement authority from the appropriate decision-maker, and communication of a fire mission to the effector. DoDD 3000.09 requirements for human judgment in the engagement decision are not waived because the environment is contested. This step requires some communication, but not necessarily persistent wide-area connectivity. A pre-positioned set of conditional engagement authorities with specified conditions and a local command node can authorize an engagement without a reach-back requirement. The architecture needs to support this explicitly.
Assess. Post-engagement battle damage assessment is routinely deferred in contested environments—BDA requires ISR access to the target area that the adversary may temporarily deny. Deferring BDA is a tactical risk management decision, not a capability failure. It delays follow-on targeting actions but does not break the kill chain.
The tracking requirement is where the DDIL architectural gap is sharpest. It is also the step where program specifications are most likely to describe performance in a connected environment and use "graceful degradation" language for the denied case without specifying what degraded performance actually means.
The architectural difference between degraded and denied
Degraded communications typically means available but slow—higher latency, reduced throughput, interruptions measured in seconds. Established techniques address this: adaptive datalink management, message prioritization, store-and-forward buffering, tolerance for out-of-order message delivery. Most JADC2 programs handle degraded scenarios adequately.
Denied communications means zero connectivity for a sustained period. The store-and-forward buffer empties. The node either operates autonomously on local data or it stops. This is a categorically different engineering problem.
A system designed for degraded-but-available communications fails in a predictable way when connectivity disappears: it queues messages, retries connections, and eventually surfaces a connectivity alert. What it does not do—unless explicitly designed to—is continue operating based solely on local data and pre-positioned state. That requires making a fundamentally different architectural choice: the node must be capable of standalone operation, with explicit specification of what outputs it produces when it cannot reach any external resource.
The Pacific MDTF scenario anticipates periods of full communications denial, not degraded connectivity. An adversary employing advanced EW against a formation's satellite links during a high-tempo engagement phase is not going to leave intermittent connectivity available. The contested window may last hours. An MDTF that cannot sustain targeting through a sustained communications blackout cannot accomplish its core mission.
This is the question that identifies whether a program's DDIL specification is real or a placeholder: not "does your system function in degraded connectivity?" but "does your system produce actionable targeting outputs when network connectivity is zero and stays zero for two hours?"
Three architectural requirements that DDIL operations actually demand
These are not exotic requirements. They follow directly from the MDTF operational concept. Programs that specify them early avoid redesign at operational test.
1. Local compute with sufficient data to operate independently. The processing node that produces targeting tracks for an MDTF cannot depend on a cloud-hosted fusion engine or a reach-back intelligence repository. It needs access, co-located or on organic transport, to the sensor data, fusion models, and prior tracks required to continue updating targeting solutions from organic sensors alone. This is not solely a cache-size question—it requires specifying what data must be pre-positioned before the formation enters a denial zone and what the node generates locally from its organic sensors during the denied period.
2. Pre-positioning and synchronization protocols before the denial window opens. Formations entering an anticipated denied area need a defined procedure for synchronizing state—current target tracks, deconfliction data, current orders and conditional authorities—before communications are lost. This is an operational planning function, but the system architecture must support it: versioned state snapshots, defined synchronization windows, and an authoritative data source when the formation operates isolated. Programs that do not specify this will have operators improvising synchronization procedures under time pressure at the worst possible moment.
3. Explicit behavior specification for the denied period. What exactly does the system do when it has no data from outside the local network? This requires written requirements: does it continue tracking with organic sensors only? Does it adjust the firing solution confidence bounds? Does it generate operator alerts without waiting for external acknowledgment? "Graceful degradation" is not a specification—it is a placeholder for a design conversation that belongs at System Requirements Review, not in the OT&E finding report.
What this means for program offices—and for acquisition testing
The test challenge for DDIL architectures is that degraded and denied scenarios are structurally underrepresented in developmental test events. Integration labs and developmental test ranges typically have high-quality network connectivity. Simulated denial events often use controlled packet-loss rather than genuine RF denial, which catches protocol failures but not the failure modes that appear when an entire data source disappears for an extended period.
Operational test plans need to include at least one sustained zero-connectivity event long enough to require the formation to make engagement decisions on local data alone. The duration should come from intelligence-derived estimates about adversary EW duration and operational tempo in the relevant scenario—not from a notional exercise duration. Programs that cannot state this requirement concretely by Milestone B have deferred a question that adversary EW operators have already answered.
Defense acquisition guidance and the DoD JCTD and rapid fielding pathways do not automatically require DDIL-specific test events. Program offices need to specify this requirement in their test and evaluation master plans and coordinate with the test community early enough to plan realistic denial conditions. That planning conversation typically requires at least two years of lead time to affect the test infrastructure.
The MDTF formations have six-plus years of experimentation with this gap, from the 2017 activation of the 1st MDTF through Project Convergence iterations beginning in 2020 and continuing through Pacific-focused exercises since, those formations understand precisely what their current systems cannot do in the denied case. The acquisition challenge is translating that operational knowledge into precise capability thresholds—specific sensor configurations, specific denial durations, specific output quality standards—that contractors can design to and test agencies can evaluate against.
The combination of local compute, pre-positioned data synchronization, and explicit denied-period behavior specification is not an ambitious wish list—it is the minimum design for a C3 architecture that can sustain the kill chain in the environment MDTF formations are specifically built to fight in. Programs that substitute "JADC2-connected" for "JADC2-capable when connectivity is absent" are writing requirements for a different operational scenario.
Spartan X's BRIC platform was designed for this exact gap: an edge AI platform built for intelligence analysis and data fusion in denied, disconnected, intermittent, and low-bandwidth communications environments, with local compute that continues processing and producing actionable outputs without reach-back connectivity. The design choices BRIC makes about local inference, data pre-positioning, and standalone behavior are the same choices that MDTF-supporting programs need to make explicit in their specifications.
Sources and further reading
- TRADOC Pamphlet 525-3-1, *The U.S. Army in Multi-Domain Operations 2028*, U.S. Army Training and Doctrine Command (tradoc.army.mil)
- JP 3-60, *Joint Targeting*, Joint Chiefs of Staff (jcs.mil — public release version)
- DoDD 3000.09, *Autonomy in Weapon Systems*, Department of Defense (requires verification of current version date)
- Army Futures Command Project Convergence findings and after-action publications (army.mil/futures)
- OUSD(R&E) guidance on AI-enabled system test and evaluation (acquisition.gov / dau.edu)
