The integration tax
Ask any program office where its schedule went and the answer usually involves integration. A new camera needs an adapter to the tracker. The tracker needs an adapter to the map. A new drone needs an adapter to the tasking tool, and a second drone from a different vendor needs another one. Each adapter is small. Together they grow with the square of the number of systems, and they break every time one side changes.
The DoD Data Strategy asked for data that is visible, accessible, understandable, linked, trustworthy, interoperable, and secure. The Army is applying the same idea at scale with the common data baseline for NGC2. The tactical edge needs it most and has it least.
One ontology for the mission
EdgeLance now has a single ontology across every part of the mission. It defines the things a mission is made of: observations, tracks, assets, tasks, directives, and receipts. It defines how they relate, what traits they carry, and which operations can act on them. The ontology generates libraries for the services that use it, so a detection produced in one place is understood the same way everywhere else.
A camera detection and a drone's position report are both observations with a location, a time, a source, and a confidence. The tracker does not need to know which vendor made the camera. The tasking engine does not need to know which vendor made the drone. They agree on the vocabulary, and that is enough.
Capabilities as blocks
On top of the ontology, every capability ships as a block. Object detection turns camera feeds into observations. ADS-B surveillance turns aircraft broadcasts into observations. Vehicle telemetry reports friendly positions and health. Track custody fuses observations into tracks. Asset tasking offers tracks to available assets. Plan dispatch turns approved plan tasks into signed directives. Maritime fusion builds the surface picture.
Each block declares what it consumes, what it produces, and which operations it is allowed to perform. Each one packages as an optional component of the EdgeLance install, so an air-gapped deployment carries only the blocks its mission needs. Five of them chain together today, from a vehicle reporting its position to a dispatched task with a receipt, running end to end on a disconnected cluster.
Valid before it deploys
Because blocks declare their inputs and outputs, EdgeLance can check a composition before anything is installed. Ask for asset tasking without a source of asset positions and the composer says so, and says which block would supply them. A package that would deploy cleanly and then sit idle waiting for data it will never receive gets caught at design time.
The same catalog is exposed to AI agents through the Model Context Protocol. An agent asked to assemble a mission capability works from the blocks that exist and the rules that connect them, so what it produces is valid by construction instead of plausible and broken.
Each block is also an optional component of the signed air-gap package, so a program accredits only what its mission uses. The tasking chain these blocks form is the one we argued for in the bomber drone post, and the shared vocabulary is what a four-star autonomy command will need underneath it.
Compose instead of integrate
The goal is to make adding a capability feel like adding a block instead of starting a project. A new sensor that speaks the ontology is useful to the tracker, the map, and the tasking engine the day it arrives. That is how the edge catches up to the enterprise on data, and how a program spends its schedule on the mission instead of the adapters.
The blocks available today are listed on the platform page. The full argument, with the history behind it, is in the whitepaper Composable Mission Software.