For two decades, military logistics software was built on a comfortable assumption: the rear is safe. Supplies flowed forward through a stable network of large depots, the data link was always up, GPS always answered, and the only adversaries were delay and cost. That assumption is gone. Long-range fires, ubiquitous surveillance drones, cyber intrusion, and electromagnetic warfare mean every supply node and every route is now targetable, from the strategic port to the forward line of troops. Contested logistics software is the response – a class of system designed to sustain the force when the adversary can strike, jam, intercept, or watch the supply chain at any point.

This article describes what changes when survivability replaces efficiency as the primary design goal: how the planning model shifts to distributed stocks, how routing becomes a function of threat rather than traffic, how demand sensing pre-stages supply instead of reacting to shortfalls, and how the whole stack is engineered to keep working on a network that is degraded, denied, or intermittent. It is a companion to our analysis of the underlying defense supply chain software architecture.

What "contested" changes about the logistics problem

In a permissive environment, the logistics optimization problem is well understood: minimize landed cost and cycle time subject to capacity constraints. Consolidate inventory into a few large nodes for economies of scale. Run lean. Trust that the truck that left the depot will arrive. Commercial supply chain platforms are exquisitely tuned for this world, and within it they are excellent.

Contested logistics inverts every one of those assumptions. A single large depot is no longer an efficiency – it is a single point of catastrophic failure, one precision strike away from removing days of sustainment for an entire formation. Lean inventory becomes brittle when a route is interdicted and the next delivery is uncertain. The truck that left the depot may be rerouted three times, may go dark for hours when its radio is jammed, and may need to find a surviving cache because its planned destination was struck. The optimization target is no longer lowest cost. It is mission continuity under attack.

Software written for the permissive world fails quietly in the contested one. It assumes a connection that is not there. It plans the shortest route through a kill zone. It shows a confident position that is actually a stale GPS fix from before the jamming started. Contested logistics software is built from the opposite premises, and those premises drive every architectural decision that follows.

Resilient visibility on a degraded network

The first casualty of a contested environment is connectivity. Cellular coverage is absent or jammed. Satellite terminals are shared, bandwidth-starved, and emit a signature that invites targeting. GPS is intermittently denied. A logistics platform that needs a live link to a central server to show anything useful is worthless precisely when it matters most.

The architectural answer is to push state to the edge and design for disconnection as the normal case, not the exception. Edge gateways at each forward logistics element buffer every sensor event – RFID gate reads, GPS positions, consumption transactions, custody scans – in a local time-series store and maintain a prioritized outbound queue. When any link becomes available, even a brief mesh-radio burst or a relay vehicle passing within range, the queue drains in priority order, most operationally significant events first. The dashboards that planners use run against this local cache, so the picture remains usable through total backhaul loss.

The discipline that makes this safe is honest staleness. Every value on every screen carries a data-age indicator. A position is shown as "live (12 s)" or "estimated, last fix 47 min ago." A stock level is timestamped against its last confirmed scan. The most dangerous failure mode in contested logistics is not missing data – operators can plan around a known gap – it is confident, wrong data that looks current. The software's job is to never let a stale picture masquerade as a live one.

Operating through GPS denial

When GNSS is jammed or spoofed, the platform degrades gracefully rather than going blank. Vehicle position falls back from GPS to inertial dead reckoning fused with map-matching against the known road network, with the resulting estimate flagged at lower confidence. Mesh-radio relay (TrellisWare, Silvus, and Persistent Systems waveforms are the common tactical options) provides relative positioning and event transport even when absolute geolocation is unavailable. The platform records which positioning source produced each fix so that after-action analysis can distinguish surveyed truth from estimate.

Distributed stock positioning

If the adversary can strike any fixed node, the counter is to make no single node decisive. Distributed stock positioning replaces the consolidated depot with a graph of many small, dispersed caches – pre-positioned, concealed, and individually expendable. Lose one to a strike and the force keeps fighting from the survivors. The price of this survivability is bookkeeping complexity: tracking inventory across dozens of locations, knowing which caches survive, and routing each demand to the nearest viable one. That complexity is exactly what the software exists to absorb.

The platform models the cache network as a graph. Each node carries its class-of-supply holdings, its last-confirmed state, and a survivability status updated from the threat picture and from custody scans. When a request arrives, the demand-routing engine resolves it against the nearest surviving cache that can fill it – not the doctrinally assigned one, which may be gone. When secure movement windows open, automatic balancing rules propose stock transfers from over-supplied to under-supplied nodes, keeping the network even without manual micromanagement.

Dispersal also shapes signature management. Many small movements between caches are harder to surveil and pattern-detect than a predictable convoy schedule into one depot. The software supports this by varying timing, splitting loads across routes, and avoiding the regular cadences that surveillance feeds on. Predictability is a vulnerability, and a system that schedules movements mechanically will manufacture exactly the pattern an adversary wants to find.

Dynamic rerouting against a threat overlay

Routing in a contested environment is not a traffic problem; it is a survival problem. The routing engine ingests a live threat overlay from the tactical common operating picture – reported enemy positions, recently interdicted routes, jamming zones, and strike locations – and treats threat exposure as a weighted cost in the path computation alongside time, distance, and hard physical constraints such as bridge weight limits, vehicle clearance, and declared no-go zones. The result is a route that may be longer and slower but that keeps the convoy out of the kill zone.

The overlay is not static. As reports arrive, recent events weigh more heavily than old ones through a decay function, so a strike reported ten minutes ago dominates planning while a contact from yesterday fades. When the overlay shifts, the engine recomputes affected routes and pushes the revision to the convoy over whatever link is available – which, in a jammed environment, may be a single compressed radio burst rather than a continuous data session. The convoy commander always retains authority to accept, modify, or reject a proposed route; the software advises, it does not drive.

This same threat-aware logic extends to the last-tactical-mile delivery, where exposure is highest and connectivity is worst. The closer supply gets to the forward line of troops, the more the software must reason about risk rather than mere distance, and the more it must tolerate operating with almost no backhaul.

Key insight: The decisive capability of contested logistics software is not any single algorithm – it is the refusal to assume. It never assumes the link is up, never assumes the depot survived, never assumes the GPS fix is current, and never assumes the planned route is still safe. Every one of those assumptions, left in the code, becomes a silent failure the moment the environment turns hostile. Survivable logistics software is software that has been audited assumption by assumption and made to degrade honestly when each one breaks.

Demand sensing and pre-staging

Reactive resupply – waiting for a unit to report it is out of fuel, then scrambling a convoy through a contested route – is the worst possible posture under threat. It concentrates movement at the moment of greatest need and least flexibility. Demand sensing flips this: the platform predicts consumption and pre-stages supply ahead of need, so that when the shortfall arrives the stock is already forward at a surviving cache.

Consumption modelling runs from rolling issue-transaction history, refined by operational-tempo predictors. Vehicle kilometres driven predict fuel burn; rounds fired predict ammunition demand; personnel fed predict ration consumption. Where these feeds are available from the fire-control and movement systems, the platform calibrates unit-specific consumption curves rather than relying on planning-factor averages that rarely match reality. The output is a projected days-of-supply figure and a zero-stock date for each class of supply at each unit.

Automated resupply triggers fire when projected days-of-supply drop below a commander-set threshold, generating a pre-filled request routed to the nearest surviving cache and surfaced to the supporting staff for approval. The intent is to convert the frantic "we are out, send a truck now" call into a calm "you will be short in 48 hours, here is the pre-staged movement" decision – made while there is still time to choose a safe route and a safe window.

Engineering for survivability, not just availability

Commercial systems pursue high availability – keep the service up. Contested systems pursue survivability – keep the mission going when the service, the node, or the link is destroyed. The distinction shows up across the stack. Data is replicated across edge nodes so that losing the central server, or losing any single forward node, does not lose the picture. Reconciliation logic resolves the conflicting state that inevitably arises when disconnected nodes operated independently and then reconnect, using event timestamps, custody chains, and last-writer rules tuned for logistics semantics.

Signature discipline is a software concern too. The platform offers a transmit-managed mode that batches and compresses uploads into infrequent bursts, minimizing emission time and the targeting signature it creates, accepting higher data latency as the price of a lower physical signature. Integration with the tactical picture is handled through the CoT protocol so that logistics tracks appear on the same common operating picture as tactical forces – on a toggleable layer, so a commander can suppress supply clutter during a contact and recall it when planning the next sustainment window. For the broader picture of fully unmanned delivery in this threat environment, see our analysis of autonomous resupply.

None of this is achieved by bolting a "contested mode" onto a permissive-environment platform. Survivability is a foundational property. It is designed in from the data model up – disconnection-first, dispersal-native, threat-aware, and honest about uncertainty at every layer – or it is not really there at all.

Build logistics that survives contact

Corvus HEAD fuses logistics tracks, threat overlays, and operator displays into one common picture that keeps planning on degraded and disconnected networks. Dispersed-stock visibility, threat-weighted routing, and demand sensing engineered for the contested fight.

Explore Corvus HEAD → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical logistics and sustainment software for defense and government organizations. Learn about our team →