Fifty minutes
In January 1991, Iraq began firing Scud missiles at Israel and Saudi Arabia from mobile launchers hidden in the western desert. Over the course of Desert Storm it launched 88 of them. The coalition put enormous effort into hunting the launchers, and by most later accounts it destroyed almost none. Crews claimed dozens. The postwar review could not confirm that fixed-wing aircraft had killed a single real launcher rather than a decoy or a truck.
The problem was rarely detection. Launch plumes are hard to miss. The problem was time. Iraqi crews drove out, fired, and withdrew in ten to fifteen minutes. Targeting data often took about fifty minutes to reach the aircraft orbiting overhead. By the time a pilot was told where to look, there was nothing left to find.
Thirty-five years later the sensors are vastly better and the munitions are vastly cheaper, but the shape of that failure is still with us. Militaries have invested heavily in seeing targets and in deciding what to do about them. The segment between an approved decision and an asset moving has received far less attention. This paper calls that segment the execution gap, describes why it persists, and sets out what software has to do to close it.
Four clocks in one kill chain
Secretary of the Army Dan Driscoll stated the standard in July: the side that can sense a target, process the data, and deliver a kinetic effect the fastest, wins. It helps to break that chain into four clocks. The sensing clock runs from an event to an observation someone can use. The decision clock runs from that observation to an approved course of action. The tasking clock runs from approval to an asset that has accepted the task. The action clock runs from acceptance to effect, and then to a report that the effect happened.
Investment has concentrated on the first two. Sensors are proliferating at every echelon. Planning and decision support is where much of the recent software money has gone, including several of the first NGC2 application awards. Those are good investments. But a faster decision clock only shortens the chain if the tasking clock keeps up, and in most formations today the tasking clock is still a person on a radio.
The fourth clock has a quieter failure. When the effect happens, the report of it often travels back by voice and never reaches the system that held the plan. The staff loses track of what was executed, the picture drifts from reality, and the next decision is made on stale information.
Why the gap persists
The execution gap survives for four reasons, and each one is reasonable on its own. The first is organizational. Planning happens at one echelon and execution at another, often across a boundary of authority. Software built for the staff stops at the staff's edge because that is where its users stop.
The second is technical. The systems that hold plans and the systems that control assets were built by different communities for different purposes. A planning tool knows about tasks, phases, and decision points. A drone's ground station knows about waypoints, battery, and payload. Neither knows the other's vocabulary, so a person translates between them.
The third is the network. The assets are at the far end of every link. The plan lives where connectivity is best. The asset lives where it is worst. Any design that assumes the plan system can reach the asset at the moment of tasking will fail exactly when the tasking matters.
The fourth is trust. An order that moves an asset has consequences, so it has to be authentic, it has to come from someone with the authority to give it, and it has to apply to the mission it claims to. Voice nets handle this with authentication tables and familiarity. Software that carries tasking has to handle it explicitly or it becomes an attack surface.
The scale problem arriving now
These reasons are old. What is new is volume. The Department is buying small drones by the hundred thousand and has asked for roughly $50 billion more to take autonomous systems from thousands of units to millions. It has added reusable bomber drones to the Drone Dominance Program, each of which turns one tasking decision into a recurring one. It has announced a four-star command whose whole purpose is employing these systems at scale.
A person on a radio can task a handful of assets. A platoon with a dozen reusable drones, a few ground robots, and a stream of targets from its own sensors cannot be tasked by voice without most of that capability sitting idle. The execution gap used to cost minutes. At the scale now being purchased, it decides how much of the purchase is usable at all.
Ukraine offers the clearest evidence of what closing the gap is worth. Its digital fire and strike coordination tools spread through units from the bottom up because they shortened exactly this segment, from a target report to an assigned shooter. The airframes and guns were often the same as their adversary's. The tasking was faster.
We have tracked this shift through the year, from the interceptor cost curve in June to the NGC2 application awards in October. Each step moved more of the fight into the segment between decision and action.
What an execution layer must do
Software that closes the execution gap has six requirements. The first is authenticity. Every directive must be signed by the authority that approved it and bound to the mission it belongs to. The receiving side must refuse anything unsigned, forged, replayed, or addressed to a different mission.
The second is asset awareness. A directive should be offered to the assets that can execute it, given their position, payload, endurance, and current work, rather than broadcast to everyone or routed by hand. Assets accept work they can do. The system tracks who holds what.
The third is liveness. A task held by an asset that has stopped responding is worse than an unassigned task, because everyone assumes it is covered. Holdings should be leases that lapse, returning the task to the pool when the holder goes quiet.
The fourth is disconnected operation. Offer, acceptance, execution, and reporting must work among the assets and operators at the edge with no path to the command post. When the path returns, the results flow back.
The fifth is a closed loop. Field receipts and the live track of the target must return to the original plan task, so the staff sees what was executed, when, and with what result, without a separate report.
The sixth is a shared vocabulary. Plans, tasks, tracks, assets, and receipts must mean the same thing to the planning tool, the tasking engine, and every vendor's platform. Without that, every new asset is a new integration and the gap reopens with each purchase.
How EdgeLance closes it
EdgeLance implements the execution layer as a chain of mission blocks that share one ontology. Plan dispatch receives approved plan tasks and turns each into a signed directive bound to its mission. It refuses unsigned or mismatched requests and dispatches only tasks against tracks the mission is permitted to see.
Asset tasking offers each directive to the assets able to take it. Assets bid based on what they can do. The winner holds the task on a lease that lapses if it goes quiet, and the task returns to the pool. Vehicle telemetry keeps the asset roster current with positions and health, accepted only from each vehicle bridge's own credentials. Track custody maintains the target picture from every available sensor, refusing spoofed, backdated, and untrusted reports, so the asset is sent toward a target the system has reason to believe in.
As the asset works, field receipts and the live target track flow back onto the dispatched plan task. The whole chain runs over the EdgeLance mesh on the team's own devices, with relay across multiple hops, and it continues among whatever nodes can still reach each other when the link to higher is gone. Every approval, dispatch, acceptance, and receipt is attributed and kept in the mission record for review.
EdgeLance is deliberately complementary to planning tools. It takes the approved tasks they produce and carries them the last mile. A staff that plans faster with a planning application and executes through EdgeLance shortens both the decision clock and the tasking clock, and closes the reporting loop that keeps the plan honest.
Each piece is covered in more depth elsewhere: the tracker that refuses spoofed reports, the mission blocks and their shared ontology, the mesh that keeps working with no peers, and the assignment logic behind asset tasking. The platform page shows how they fit into the rest of the mission workspace.
What programs should ask for
Programs fielding NGC2 applications, Drone Dominance systems, or the software that will sit under an autonomous warfare command can close much of the execution gap through requirements alone. Measure approval-to-execution time at the asset, not approval time at the command post, and report it in exercises. Require that every tasking system accept signed, mission-bound directives and refuse everything else. Require closed-loop receipts back to the originating plan task.
Test tasking with the link to higher cut, as a standard part of acceptance rather than a special event. Require vendors to produce and consume a common vocabulary for observations, tracks, assets, tasks, and receipts. And require a durable record of every tasking decision, human or machine, that survives the mission and supports review.
None of these requirements favors a particular vendor. All of them favor the soldier at the end of the chain, who currently closes the execution gap by hand.
The segment that decides the rest
The Scud hunters of 1991 could see the plumes. What they could not do was get a decision to a shooter before the target drove away. The tools are different now and the targets are smaller, faster, and far more numerous, which makes the same gap more expensive than it has ever been.
Sensors and planning will keep getting better, and programs should keep buying both. The side that wins the next fight will be the one whose approved decisions reach an asset in motion, through jamming, without waiting for a link, and report back on their own. That is the execution layer, and it is the part of the kill chain where software investment will now return the most.