Article reader Listen + reading controls
Article reader
Preparing the reader…
Reading settings
GEARS and the Architecture of Retrofit Autonomy¶
The Army’s Ground Expeditionary Autonomous Retrofit System (GEARS) is strategically interesting for a reason more durable than the selection of three vendors. It treats autonomy as a capability that can be integrated into an existing fleet rather than as a property of a newly designed vehicle.
That choice shifts the center of gravity from platform replacement to architecture. If autonomy can be added through modular navigation kits, stable interfaces, government-controlled data, and repeatable test evidence, the Army can modernize more vehicles, preserve competition, and improve software without waiting for the lifecycle of the underlying truck.
If those conditions are absent, “retrofit” merely moves vendor lock-in from the vehicle to the autonomy stack.
The Defense Innovation Unit’s GEARS project supports the Army’s Autonomous Transport Vehicle System effort by adding autonomous navigation kits to Palletized Load System vehicles. DIU selected Carnegie Robotics, Neya Systems, and Robotic Research for prototype development and evaluation, with an initial objective of 41 retrofitted vehicles and an option to extend the approach to other platforms.
The architectural question is what, exactly, becomes reusable when the kit moves to another vehicle or a new vendor enters the ecosystem.
Modularity Requires a Real Contract at the Interface¶
Programs often describe a system as modular because components are physically separable or expose APIs. Genuine modularity requires more: the interface must preserve enough meaning and stability that one component can be replaced without reconstructing the rest of the system.
For a vehicle-autonomy kit, the contract may include:
- drive-by-wire commands and safety limits;
- braking, steering, throttle, and transmission state;
- vehicle geometry, mass, payload, and dynamic constraints;
- power, thermal, compute, and network services;
- localization, mapping, perception, and obstacle representations;
- autonomy modes, health, and confidence;
- remote-supervision and intervention mechanisms;
- logging, time synchronization, and event provenance;
- cybersecurity identities, update paths, and trust boundaries;
- and test procedures demonstrating conformance.
A document is not enough. Conformance must be executable: automated interface tests, reference implementations, simulation environments, hardware-in-the-loop tests, and operational scenarios that reveal whether a new component behaves as the larger system expects.
This is how an interface becomes a market rather than a diagram.
Government Ownership Should Target Leverage Points¶
The government does not need to own every line of autonomy software. It does need control over the leverage points that preserve operational freedom and competition.
Those include:
- the right to access and export mission, test, and telemetry data;
- documented interfaces and the ability to validate conformance;
- cryptographic and update authorities appropriate to the mission;
- system-level safety and assurance evidence;
- integration environments and representative test scenarios;
- the ability to replace a component or support provider;
- and sufficient technical data to investigate incidents and sustain the fleet.
DIU’s broader autonomous-vehicle work highlights Traceability, Observability, Replaceability, and automated Consumption (TORC) compliance for Army software-centric ground vehicles. Those concepts point toward the correct objective. Traceability makes claims and changes reconstructable. Observability makes behavior measurable. Replaceability protects technical and commercial options. Automated consumption allows components to integrate through machine-readable contracts rather than recurring manual effort.
Together, they define an architecture for continuous competition.
Retrofit Economics Depend on the Integration Curve¶
The apparent advantage of a kit is that the government can spread development across a large installed fleet. Whether the advantage materializes depends on the marginal cost of each integration.
If every vehicle requires a unique sensor layout, control adapter, safety case, training package, cyber authorization, and maintenance pipeline, the “kit” becomes a series of bespoke programs. If the architecture captures platform variation explicitly and reuses evaluation evidence, each additional integration should become cheaper and faster.
Program leaders should therefore track:
- engineering hours per new vehicle type;
- percentage of software and tests reused unchanged;
- time to integrate a new sensor, algorithm, or vendor component;
- cost and duration of renewed safety and cyber evaluation;
- defects caused by interface ambiguity;
- time required to reproduce and diagnose field incidents;
- and competitive switching cost.
The declining integration curve is the economic proof of modularity.
Safety Cases Must Be Composable¶
Autonomous systems are evaluated as combinations of hardware, software, environment, mission, and human supervision. Replacing a component can invalidate system-level safety evidence even when the new component meets the same nominal interface.
A modular program therefore needs composable assurance. Each component should carry structured claims about:
- supported operating conditions;
- performance bounds and known failure modes;
- required inputs and their quality;
- behavior under missing, delayed, or contradictory inputs;
- cybersecurity and supply-chain assumptions;
- interactions with human operators and supervisors;
- and the tests and evidence supporting those claims.
The system integrator then shows how component claims compose for a particular vehicle and mission profile. Not every claim will compose automatically; some interactions require system-level testing. The value is in making the assumptions explicit so that a change triggers targeted re-evaluation rather than a complete restart or an unjustified presumption of safety.
Data Is the Continuity Layer¶
The most important reusable asset may not be the autonomy code. It may be the data accumulated through integration and operation:
- sensor recordings and environmental conditions;
- intervention and disengagement events;
- labeled edge cases;
- simulated and live test results;
- vehicle health and maintenance history;
- software and configuration versions;
- and mission outcomes.
If this evidence remains inside separate vendor environments, the Army cannot compare systems fairly, train future models efficiently, or understand fleet-level risk. A government-governed data layer—protected for security, privacy, proprietary information, and mission sensitivity—allows learning to survive contract boundaries.
That layer should preserve provenance. A training example without its vehicle configuration, sensor calibration, environment, and operational context can be misleading. Autonomy data is not an undifferentiated fuel; it is evidence whose meaning depends on the conditions under which it was produced.
Open Architecture Must Include the Toolchain¶
An open runtime interface is insufficient if only one vendor can build, test, deploy, and diagnose the software. The delivery toolchain is part of the architecture.
The government should ensure that authorized teams can:
- reproduce builds;
- run automated tests;
- deploy signed updates;
- compare model and software versions;
- inspect telemetry using common schemas;
- roll back a defective release;
- and recreate the operational configuration associated with an incident.
This does not imply unrestricted access or insecure development. It implies a governed platform in which multiple qualified participants can contribute without surrendering control of the fleet’s evolution.
Competition Should Continue After Selection¶
The three-vendor prototype phase creates discovery through competition. The conventional next step—a winner takes the program—may undermine the modularity the project seeks.
A healthier model preserves competition at meaningful layers:
- vehicle integration;
- perception and localization components;
- planning and control modules;
- simulation and test services;
- remote-supervision tools;
- cyber and safety evaluation;
- and sustainment.
This does not mean changing vendors arbitrarily or fragmenting accountability. A system integrator must remain responsible for end-to-end performance. It means maintaining the technical and data rights that make alternative suppliers credible and using conformance evidence to reduce the cost of switching.
The Strategic Inference¶
GEARS is more than a pathway to autonomous logistics vehicles. It is a test of whether the Army can treat a physical fleet as a continuously evolving software-defined capability.
The retrofit approach will succeed if the government controls interfaces, evidence, data, and delivery mechanisms strongly enough that innovation can occur above and below the platform boundary. It will fail if the kit becomes a closed appliance whose internal architecture, operational data, and assurance evidence cannot move with the mission.
The central product is therefore not the autonomous kit. It is an ecosystem in which autonomy can be integrated, evaluated, replaced, and improved without replacing the Army’s freedom of action.
This essay was substantially revised in July 2026. The recovered page’s original body had been mismatched to its GEARS headline and URL; this revision restores the intended subject and develops a distinct architecture-and-acquisition analysis.
For organizations applying modular AI and software architectures to legacy mission platforms, Xendev Labs is the practical extension of my work on AI engineering and transformation systems.
References¶
- Defense Innovation Unit, “GEARS Project Brings Autonomy to the U.S. Army’s Sustainment Fleet,” December 14, 2023.
- Defense Innovation Unit, “Accelerating Autonomous Vehicle Technology for the DoD.”
- Jen Judson, “GEARS of war: US Army picks 3 companies to advance autonomous resupply,” C4ISRNET, December 19, 2023.