Why the sky runs out of coordination before it runs out of space

There is a natural assumption, when people first look at low-altitude airspace, that the binding constraint is room. Ask how many drones a city can support and the instinct is to divide the volume of navigable air by the volume each vehicle needs, apply a safety margin, and report a number in the millions. The number is real. It is also almost entirely irrelevant, because a city's airspace does not fail when it runs out of room. It fails, much earlier, when it runs out of the ability to coordinate the vehicles already using the room.

Coordination is the scarce resource. And unlike airspace, coordination capacity is not a fixed physical quantity — it is a property of the protocol you choose. Two systems managing the same cubic kilometre of sky, with the same vehicles and the same weather, can differ by orders of magnitude in how many simultaneous operations they can safely handle, purely because of how the coordination is structured.

This post is about that structure: where the conventional approaches hit a wall, why the wall is made of coordination rather than space, and the three specific design decisions that move it. I will try to be precise rather than promotional, which means being explicit about what is proven, what is argued from construction, and what is still open. The last category is larger than a marketing document would admit and exactly as large as an honest one must.

§Three ways to keep two aircraft apart

Deconfliction — the task of ensuring two vehicles are never in the same place at the same moment — has three broad architectures. Each of them works. Each has a density at which its cost curve bends upward, and then goes vertical.

A central scheduler. An authority collects everyone's plans and computes a conflict-free schedule. This is clean, auditable, and optimal at low traffic. The problem is the checking: to guarantee no two plans collide, the scheduler must compare plans against each other, and the number of comparisons grows super-linearly — toward the square of the fleet size in the dense worst case. Add the fact that every vehicle must reach the authority and wait for an answer, and you have both a computational bottleneck and a single point of failure. Central scheduling is excellent for sparse, high-value operations. It is the wrong tool for a sky with tens of thousands of small vehicles making short trips.

Pairwise avoidance. Give each vehicle the job of staying clear of every other vehicle it can see — see-and-avoid, and its digital descendants. This removes the central bottleneck, which is why it is attractive. But it relocates the cost onto every vehicle, and that cost grows with the square of local density: a vehicle with k neighbours inside its interaction radius has on the order of k² pair-interactions to monitor and resolve. At low density this is nothing. At high density every vehicle spends progressively more of its time and radio negotiating and less of it flying, until the airspace is busy doing nothing but avoiding itself.

Fixed corridors or tubes. Pre-carve a set of routes and require everyone to fly inside one. Deconfliction collapses into scheduling along a line, which is genuinely easy. The catch is that a city does not have a small number of origin-destination pairs; it has an enormous number, and they change by the hour. You cannot tile arbitrary point-to-point demand with a manageable number of tubes, and the moment demand is asymmetric — as it almost always is — the reserved capacity of the empty direction is simply stranded.

The common thread is the thing worth noticing. In all three, the cost of keeping vehicles apart is coupled to the number of vehicles that might interact. That coupling is the wall. Everything that follows is about breaking it.

§The cheapest conflict is the one that never happens

The first move is the largest, and it is almost embarrassingly simple to state: if two vehicles travelling in different directions are always at different altitudes, then most of the conflicts you were about to coordinate never exist to begin with.

This is what Altitude Encodes Direction buys you at the level of the whole system. The mechanism has its own post — how six directions map onto altitude bands, why the encoding is stable under sensor noise — but the systems consequence is what matters here. A conflict prevented by geometry never enters the coordination budget. No message is sent. No cycle is spent. No negotiation is opened. The crossing traffic that would dominate a pairwise system's workload is separated for free, continuously, by a quantity every vehicle already broadcasts.

This reframes the whole problem. The other three architectures try to make coordination cheaper. Encoding tries to make most of it unnecessary — to delete the demand rather than optimise the supply. That is a categorically bigger lever, because the demand you delete scales with the traffic, so the saving grows exactly as fast as the problem does.

I should be careful about what this does not do. Altitude-direction encoding gives you a static separation guarantee, not a dynamic one. Two vehicles travelling the same direction, in the same band, can still converge — one overtaking another, two merging into a corridor, one descending through another's level to land. Encoding does not touch those. It removes the large, structural, crossing-traffic conflicts and leaves a much smaller residual of same-direction, same-region interactions. The rest of the protocol exists to handle that residual — and, crucially, only that residual.

§Making the coordination that remains flat, and bounded

Two design decisions handle what encoding leaves behind. The first flattens its cost. The second caps its worst case.

Flat, via reservation. Under Hex-Cell Capacity and the 4D Space-Time Reservation primitive, a vehicle does not coordinate against the fleet. It claims a sequence of (cell, direction-band, time-window) tuples along its own path, and each claim is checked only against that cell's own occupancy count. The cost of reserving is a function of your trajectory length — how many cells you pass through — and is completely independent of how many other vehicles are in the sky. Ten vehicles or ten thousand, your reservation costs the same. The cell-level argument is here; the system-level consequence is that the residual coordination no longer couples to N. The curve that bent upward in all three conventional architectures goes flat.

Bounded, via determinism. Sometimes two vehicles genuinely must negotiate — a same-direction merge, a capacity edge, an emergency reroute. AACP allows that negotiation but refuses to let it become the failure mode that pairwise systems suffer. It is time-boxed: at most three rounds, within a hard 500-millisecond ceiling. And if it does not converge, the vehicles do not keep talking. Both independently compute the same resolution from the parameters they already exchanged, following a fixed priority order — Emergency > Passenger > Cargo > Commercial > Recreation, then remaining energy, then heading, then vehicle identifier. What AACP negotiates, and what it refuses to, is its own subject. The point for scaling is narrow: even the residual-of-the-residual has a bounded cost that cannot expand under load. There is no configuration of traffic that turns one negotiation into an unbounded cascade.

Put the three moves together and the shape of the system changes. Encoding deletes the bulk of the conflicts; reservation makes the survivors O(1) per request; deterministic fallback caps the exceptions. Coordination cost per vehicle stays roughly flat as density climbs. The system stops being limited by coordination complexity at all.

§What the scenarios actually probe, and what they don't

It would be easy to end there, draw a flat line next to three upward curves, and call it proof. It would also be dishonest, so here is the careful version.

VerSky publishes three reference scenarios as machine-readable JSON. They are illustrative probes of specific filed paragraphs — not validated conformance baselines, and not measured benchmarks. The distinction matters enough that it is printed on the dataset files themselves.

Take the one most relevant to this argument, asymmetric-surge-v1. It defines twenty-four northeast-bound vehicles requesting passage through a four-cell corridor over a sixty-second window, against only four vehicles heading southwest — an arrival rate of 0.4/s one way and 0.067/s the other, through cells with a capacity of eight each. What it is designed to exercise is direction-band saturation under Hex-Cell Capacity: the dominant flow should throttle at the cell-capacity bound while the sparse inverse direction stays completely unaffected, and — the property that matters — no gridlock appears. The asymmetry that strands capacity in a corridor system is absorbed here.

What that scenario does not give you is a throughput curve or a closed-form capacity bound. The analytical upper bound on directional throughput as the vehicle-speed distribution shifts is, honestly, unsolved — it is the first of the open research questions for a reason. The determinism claim (both vehicles computing an identical fallback) is a property you can test, and it is tested against the reference scenarios. The scaling claim is argued from construction, and it awaits open benchmarking at the ten-thousand-vehicle scale on commodity hardware, which is another of the open questions and not yet answered.

§Where the wall actually is

Here is what the three moves actually accomplish, stated plainly. They do not raise the ceiling on how much air a city has. They change which ceiling you hit first.

In the conventional architectures, the binding constraint is coordination complexity, and it is the bad kind of limit: it arrives without much warning, it scales with the square of your own success, and you cannot buy your way out of it by putting better hardware on the vehicle. When you move that constraint out of the way, the next one you meet is the physical capacity of the airspace itself — cell capacity, separation minima, vehicle performance. That is the good kind of limit. It is local, so you can reason about it a cell at a time. It is a resource, so you can schedule it, price it, and reserve against it. And it responds to engineering: tighter sensors and smaller separation minima expand it directly.

Move the wall from coordination to space, and for the first time the millions-of-drones arithmetic from the opening paragraph stops being a fantasy and becomes the number you are actually managing toward. That is the entire point of the protocol. Not to make the sky bigger — to make coordination stop being the thing that runs out first.

There is a great deal of work left in the gap between "argued from construction" and "demonstrated at scale," and I have tried to be honest above about where that gap is. If you build low-altitude systems, the reference implementation and integration path are where the encoding and reservation primitives become code. If you are an operator or a prospective licensee, how adoption works is the relevant door. And if you are a researcher — particularly if you can close the throughput bound or stand up the ten-thousand-vehicle benchmark — the open questions and datasets are genuinely open, and the academic contact line reaches me directly. Objections from physics, regulation, or operations are the most useful mail I get.