Contested Is the Baseline: Designing for the conditions that jeopardize missions

Executive Summary

Contested environments don't always require adversary action; geography, climate, distance, and infrastructure limits can degrade system performance before a shot is fired. Yet most defense systems are still optimized for cooperative conditions, with contestation treated as an edge case to be simulated or addressed after the fact. When underlying assumptions about connectivity, power, and positioning fail, capability erodes quickly. The alternative: design backward from contested conditions, treating degraded environments as the baseline.

Redefining Contested

The defense community often describes contested environments in terms of adversary action: jamming, cyber intrusion, kinetic strikes, electronic warfare. That framing is accurate - but incomplete.

A contested environment is any condition in which a system’s underlying assumptions stop holding. Adversary actions like jamming or cyber intrusion create contestation, but so do geography, climate, distance, and infrastructure limits. GPS degrades at high latitudes due to satellite geometry and ionospheric effects – without deliberate interference. Communications fail when forces operate beyond available infrastructure. Supply chains strain under extreme temperature, time, and distance.

Contestation does not require an adversary to act first. In many theaters, the environment itself removes cooperation before a single shot is fired.

A Common Failure Mode

A Wall Street Journal article examining NATO operations and testing in the Arctic described U.S. military vehicles breaking down within minutes as hydraulic fluids froze, night-vision optics shattering in minus-40-degree temperatures, and GPS becoming unreliable closer to the North Pole. Magnetic disturbances distorted satellite signals. Batteries drained in minutes. Navigation systems lost reference points across snow-covered terrain.

Separate analysis from the U.S. Army examined operations in space-contested environments, emphasizing that GPS degradation, disrupted ISR, and intermittent SATCOM are no longer edge cases but conditions that must be assumed in maneuver planning. And reporting on unmanned systems highlights how distributed, autonomous platforms are increasingly necessary to maintain operations when traditional communications and positioning are degraded or denied.

Though these cases span different domains - Arctic operations, space-contested environments, distributed autonomous systems - they converge on a common failure mode: systems optimized for cooperative conditions fail quickly when basic dependencies (like power, positioning, and connectivity) become unreliable.

When Contested Is the Operating Reality

When system assumptions fail, the impact is rarely immediate or obvious.  They erode. Leaders lose confidence in the data they're seeing. Maintenance timelines stretch without clear explanation. Supply and readiness decisions rely on stale or partial information. By the time movement or sustainment becomes visibly constrained, decision space has already narrowed.

Peacetime development naturally favors efficiency and performance under stable conditions. Conflict strips those conditions away, revealing which systems were designed to endure disruption, and which were not. When those assumptions fail all at once, adding resilience later is rarely sufficient.

The solution is to start from contested conditions and design backward - accepting environmental friction, degraded connectivity, and infrastructure limits as baseline requirements rather than exceptions. Designing from contested conditions changes what gets prioritized, what gets accepted as risk, and what must keep working when assumptions fail. In practice, it leads to different system architectures and different operational behaviors.

This design philosophy is increasingly reflected across DoD programs, from distributed kill webs to expeditionary logistics nodes, where resilience under degraded conditions has become a first-order requirement, not an afterthought. It requires baking contested conditions into developmental and operational test from the start, representing degraded communications, power constraints, and infrastructure limits as baseline test scenarios, not edge-case vignettes.

In INDOPACOM, the environment creates contested conditions before any adversary acts. The AOR spans roughly 52 percent of Earth's surface - 100 million square miles, most of it water. Distance degrades communications. Infrastructure is sparse by default. The Army's Next Generation Command and Control prototype, currently being tested with the 25th Infantry Division, reflects this reality — built and tested in an operationally representative environment where intermittent connectivity is expected, not simulated. The interface pulls data from multiple sensors and systems to enable faster decisions specifically because it's architected to function when networks are stressed. Exercises like Lightning Surge add complexity, but the foundation assumes enterprise reachback is not guaranteed.

In the maritime domain, platforms must operate through rough seas and extended ranges without constant control. Small unmanned surface vessels now demonstrate the ability to sustain operations in challenging sea states with enough range and autonomy to extend naval reach without relying on persistent communications or GPS. Edge-based autonomy — local mission execution, collision avoidance, health management — enables decisions without constant connection to enterprise systems. The design principle is the same: if the platform can't function independently when links degrade, it wasn't built for the environment it will actually face.

Similar constraints apply to sensor systems. Modular radar architectures designed for power-limited platforms and austere fixed sites address contested conditions that have nothing to do with adversary jamming — they exist because infrastructure and power availability are inherently constrained.

For readiness and sustainment, visibility must persist when networks degrade. Most logistics systems lose that visibility the moment connectivity becomes intermittent. Architectures like the Navy's Model Based Product Support program address this by preserving shipboard operation under disconnected conditions — maintaining local views that reconcile when connectivity is restored, rather than treating intermittent access as an exception. On the supply chain side, systems like the Enterprise Parts Management System detect vulnerabilities before they ground platforms, giving leaders theater-wide visibility to make sourcing and redistribution decisions when primary lines are severed. The principle is the same: design for the connectivity conditions that actually exist, not the ones we'd prefer.

Design Tradeoffs Under Contested Conditions

Designing for contested environments forces uncomfortable tradeoffs. It often means prioritizing resilience over peak performance, redundancy over efficiency, and open standards over proprietary lock-in. In practice: accepting onboard storage and edge compute overhead instead of thin-client architectures that assume reliable backhaul. Standardizing data schemas across systems instead of optimizing for single-platform performance. Building multi-path communications instead of minimal, single-link solutions.

Those choices can look wrong on paper; they increase upfront cost and can be undervalued in demonstrations that prioritize ideal-condition performance over endurance. In peacetime, they are easy to question. I In conflict, they determine the difference between mission success and failure.

Defense analyst Katherine Welch has argued that despite repeated warnings - particularly in logistics-focused wargames - the same vulnerabilities persist because institutions are reluctant to make different design choices. Awareness is not the constraint. Willingness is.

Building for the Conditions We’ll Actually Face

Contested environments already define where and how forces operate. The question is whether acquisition decisions reflect that reality.

Every requirement written around persistent connectivity is a requirement for a system that will underperform when conditions degrade. Every architecture that assumes reliable infrastructure is an architecture designed for an environment that will not exist in conflict.

Fixing this requires more than awareness - it requires different acquisition behavior.

Requirements must define minimum viable capability under degraded conditions, not just peak performance under ideal ones. If a system's key performance parameters don't address behavior when GPS, connectivity, or power are unavailable, the requirement is incomplete.

Developmental and operational testing must represent contested baselines. Degraded communications, intermittent power, and denied positioning should be standard scenarios from the start of a program.

And "contested" must be defined broadly enough to include the environment itself. Geography, distance, and infrastructure limits are as predictable as any threat vector.

We'll keep discovering contested conditions through failed tests until we start designing for them deliberately. Contested environments don't wait for adversary action. Neither should our acquisition and design decisions.

‍