Fifteen point eight cents
In April 1956 a converted tanker called the Ideal-X sailed from Newark to Houston carrying 58 truck trailers bolted to its deck. Loading loose cargo onto a ship at the time cost an estimated $5.83 a ton. Malcom McLean's containers went aboard for about 15.8 cents a ton, a reduction of more than ninety-five percent.
The container was a steel box. Its power came from agreement. Once every crane, ship, truck, and rail car was built to the same box, cargo stopped being handled piece by piece at every transfer. The work of integration moved out of the docks and into the standard, where it was done once.
Defense software at the tactical edge is still in the break-bulk era. Every new sensor, platform, and application is handled piece by piece at every interface. This paper describes how mission software can make the same move the shipping industry made: a shared vocabulary, capabilities packaged to fit it, and a delivery path that carries them anywhere, including networks that will never see the internet.
The integration tax at the edge
A typical tactical capability touches several systems. A camera produces detections. A tracker fuses them with other sensors. A map displays tracks. A tasking tool assigns assets. A drone's control station flies the asset. Each pair of systems that must exchange data needs an adapter that translates one side's format into the other's.
The number of possible pairs grows roughly with the square of the number of systems, and each adapter is a small project with its own testing, accreditation, and maintenance. When either side changes, the adapter breaks. Programs routinely spend more schedule on these seams than on the capabilities they connect.
The enterprise has started to address this. The DoD Data Strategy set goals for data that is visible, accessible, understandable, linked, trustworthy, interoperable, and secure. The Army's NGC2 program built a common data baseline with industry and is now buying applications to run on it. The tactical edge, where systems are most numerous and connectivity is least reliable, needs the same discipline and usually gets it last.
Capabilities as blocks
The second element is packaging. Each EdgeLance capability ships as a mission block: a self-contained component that declares, in a manifest, what it consumes, what it produces, and which operations it is permitted to perform. Current blocks include object detection, ADS-B surveillance, vehicle telemetry, multi-domain track custody, asset tasking, plan dispatch, and maritime fusion.
Declared operations are a security boundary as well as documentation. A block runs with its own credentials and may publish and subscribe only to the topics its manifest names. A detection block can produce observations. It cannot dispatch a task. The broker enforces the boundary and the consuming block checks it again.
Blocks compose into mission capabilities. Five of them form a complete tasking chain today, from a vehicle reporting its position, through track custody and asset tasking, to a signed and dispatched plan task with a receipt, running end to end on a disconnected cluster.
Valid by construction
Because every block declares its inputs and outputs, a composition can be checked before it is deployed. EdgeLance's composer validates that every input a block needs is supplied by some other block in the composition. Request asset tasking without a source of asset positions and the composer reports the gap and names the block that would fill it. A package that would install cleanly and then sit idle, waiting for data that will never arrive, is caught at design time instead of in the field.
This matters more as AI agents begin to generate deployment configurations. An agent asked to write packaging from scratch can produce something plausible that does not work. EdgeLance exposes its block catalog through the Model Context Protocol, so an agent assembling a mission capability works from blocks that exist and rules that connect them. Its output is constrained to valid compositions. The agent proposes and the validator decides.
The blocks themselves are described in Build the mission from blocks that already agree on what a target is. The chain they form is the subject of a companion paper, The Execution Gap.
Delivered to networks that will never see the internet
The third element is delivery. Composable software is only useful if the composition can reach the places it is needed, and many of those places are air-gapped. EdgeLance packages for disconnected Kubernetes environments as a single signed artifact. Each block is an optional component of that package, so a deployment carries only the blocks its mission requires and its accreditation boundary stays as small as the mission allows.
Credentials for the message broker and every block come from a single managed secret, and containers run with read-only root filesystems. Each release produces its software bill of materials, including the license of every model it carries, from the same build that produces the software. Every model in the default loadout is permissively licensed, in line with DoD guidance that open source license terms still apply.
The same blocks run outside the cluster as well, on laptops and phones in the field, sharing state over the EdgeLance mesh. A capability composed for the forward server and a capability running on an operator's device speak the same vocabulary.
The security page describes these controls in more detail, and the post on model licensing explains why the bill of materials now includes every model's license.
Who should own the vocabulary
A shared vocabulary is a source of power, and someone will hold it. If a single vendor defines what an observation or a task means, every other vendor integrates on that vendor's terms, and the program inherits a dependency it never chose. The container standard worked because no shipping line owned it.
The ontology for a mission should belong to the government that runs the mission. Vendors should be able to read it, map to it, and propose additions, but the definitions should sit in a repository the program controls, versioned like any other configuration item. This is the data equivalent of owning the models and owning the record. The unit that owns its vocabulary can change vendors without changing how its mission is described.
EdgeLance generates its libraries from a single descriptor for exactly this reason. The descriptor is the source of truth, the code follows from it, and a customer who takes delivery of the descriptor holds the vocabulary their mission runs on.
Composition at the tactical edge
Composition matters most where integration is hardest. A forward server can run a full composition of blocks inside a cluster. An operator's phone runs a smaller set. The same vocabulary connects them, so a detection produced on a phone and a track produced on the server are the same kind of object, and the mesh can carry either one between devices without translation.
That property changes how a unit adapts in the field. A team that gains a new sensor mid-deployment does not wait for an integration contract. If the sensor's block speaks the ontology, the tracker, the map, and the tasking engine can use it as soon as it is approved and staged. The mission pack that carries the block to each device is the same one that carries its models, so the fit check and the signature cover both.
What programs should ask for
Programs can push the whole ecosystem toward composability through requirements. Ask vendors to publish the vocabulary their systems produce and consume, and to map it to a common ontology. Ask that every component declare its inputs, outputs, and permitted operations in a machine-readable manifest. Ask that compositions be validated before deployment, and that the validator, not the integrator, decide whether a configuration is complete.
Ask that every component be deliverable as an optional part of a signed, air-gapped package, with its own least-privilege credentials. And ask that model licenses appear in the bill of materials. None of these requirements is exotic. Together they move integration out of every program's schedule and into the standard, where it is done once.
The box was the breakthrough
The container made everything fit, and the savings followed. Mission software at the edge is at the same point. The sensors are capable, the platforms are plentiful, and the money is flowing. What is missing is the agreement that lets them be composed instead of integrated.
EdgeLance is built on that agreement: one ontology, capabilities packaged as blocks that declare how they fit, compositions validated before they deploy, and a delivery path that reaches the disconnected networks where the mission actually runs.