What AACP actually does (and what it deliberately doesn't)

Two posts in, the underlying picture is in place. Altitude encodes direction. Hex cells provide the spatial substrate. Reservations provide the coordination primitive. None of it, so far, has involved any artificial intelligence in any meaningful sense — the geometry and the encoding are entirely deterministic.

This is where readers from the AI side of aerospace tend to interrupt: if it is all deterministic, where does the AI come in, and why does the second filed patent describe an "AI Aerial Communication Protocol"?

The answer is the subject of this post, and it begins with a confession. A great deal of AACP's design is about preventing AI from doing the wrong things. The AI layer exists; it does real work; it is genuinely useful. But the load-bearing safety properties of the system are deliberately kept out of it.

§What "AI in airspace" usually means

When people talk about AI in air traffic management they typically mean one of three things, and it is worth keeping them separate.

The strategic sense — AI planners that optimise traffic flow across hours or days, modelling demand, weather, and operational constraints to produce schedules that humans then approve. This is largely uncontroversial because the AI is advisory; the humans hold the authority.

The tactical sense — AI controllers that issue clearances or commands to specific aircraft in real time, replacing or augmenting a human controller. This is controversial because the AI now holds operational authority over moving vehicles, and its failure modes are the failure modes of the deployed model.

The conversational sense — AI communicating with other AI, with humans, or with mixed populations of both, to negotiate intents, share information, or resolve conflicts. This is the one that has barely been formalised at all.

AACP lives in the third sense. It is, very specifically, a communication protocol, not a control system. Its job is to let autonomous vehicles tell each other things and reach agreements about those things. It is not a controller. It does not issue commands. The airspace it operates within has its safety properties guaranteed by the deterministic substrate underneath, not by AACP itself.

§The five layers, by what they do

The protocol describes five communication layers. The application gives them letter codes for unambiguous internal reference, but they are best understood by what they accomplish.

Intent broadcasting. A vehicle declares what it is about to do, with a bounded uncertainty envelope. Not "I will be at this point at this time" — which is a forecast that ages badly — but "I intend to be somewhere within this volume in this time window, with this probability." Other vehicles read these envelopes and adjust accordingly.

Peer-to-peer negotiation. When two vehicles' intents conflict — overlapping reservations, contested cells, simultaneous claims — they negotiate directly. The negotiation is bounded in time and falls through to a deterministic resolution if it does not converge. This is the layer where most of the operational AI work actually happens.

Distributed sensing. Vehicles share observations of their environment with each other. A drone detecting an unmarked obstacle informs the airspace; the next drone passing through has prior information without needing to redetect. The protocol defines the format and trust semantics of these observations.

Trust and reputation. Vehicles maintain bounded reputations for the vehicles they have interacted with. Reputation affects how heavily their broadcasts are weighted by others. The system is structurally anti-Sybil — creating fake identities to manipulate reputation is expensive — and anti-collusion in a sense I will come back to.

Decision logging. Every consequential decision a vehicle makes is logged in a tamper-evident chain that humans can audit after the fact. This layer exists because the others involve AI judgement, and the line between AI judgement and AI accountability is human-readable evidence.

Each layer is a protocol surface, not an algorithm. The protocol specifies what gets communicated and how it gets validated. The intelligence inside each vehicle — the actual decision-making about whether to accept a negotiation, whose reputation to trust, what to share with whom — is the vehicle operator's choice and the vehicle operator's liability.

§The deterministic fallback principle

I want to spend the rest of this post on what I consider the single most important design decision in AACP, which is the layer underneath all five layers I just described.

Every AACP negotiation has a time bound. If two vehicles begin negotiating over a contested cell and have not reached agreement within that bound, the negotiation stops, and the conflict is resolved by a deterministic rule that does not involve AI at all.

The deterministic rule is part of the protocol. It is described in the filed application and implementable in a handful of lines of code. It uses information every participant already has — and applies a four-level priority hierarchy: (1) mission priority class, (2) remaining energy level, (3) current heading value, and (4) vehicle identifier as final tie-break. The result is an outcome that every observer can independently verify.

This sounds like a small thing. It is the load-bearing wall of the entire safety argument.

Here is why.

An AI-based negotiation, however sophisticated, has failure modes that are model-specific. The model may misjudge intent, mishandle adversarial inputs, fail to converge, or simply behave anomalously under conditions outside its training distribution. These failures are real, they are documented across every deployed AI system at scale, and they do not go away with better training. They are properties of the medium.

If the resolution of a negotiation depended on the AI converging, every one of those failure modes becomes a safety failure of the airspace. A model that hesitates is a model that lets two vehicles arrive at the same place. A model that loops is a model that prevents anyone from reserving the cell at all. A model that hallucinates a fake claim is a model that locks out a legitimate one.

The deterministic fallback severs this dependency. AI negotiation is permitted because it is useful — most of the time, two reasonable models will converge on a more efficient outcome than the deterministic rule would have produced. But the safety of the airspace does not rest on AI convergence. It rests on the fallback. The fallback exists precisely so that AI negotiation can fail without the airspace failing.

§What this lets the AI side actually do

Once the deterministic fallback is in place, the AI layer becomes much less scary to design and much more useful in practice.

Vehicles can negotiate aggressively — proposing creative routings, swapping reservations, building convoys, optimising for fleet-wide objectives — because the worst-case outcome of a failed negotiation is the fallback, not an accident. This is the same logical structure that makes optimistic concurrency control safe in database systems: bold attempts are encouraged because rollback is guaranteed.

Vehicles can use whatever AI techniques they like — classical optimisation, reinforcement-learning policies, large-language-model-based reasoning, anything — because the protocol only constrains the interface, not the implementation. The protocol's contract is: speak AACP, honour the deterministic fallback, log your decisions. What happens inside the vehicle's brain is the operator's design space.

Vehicles can fail without taking the airspace down. A drone whose AI model crashes mid-negotiation defaults to the fallback. A drone whose reputation has been corrupted by an adversary is downweighted until the corruption is detectable. A drone whose decisions look anomalous in the logs can be audited after the fact and, if necessary, banned from the airspace.

The shape of the system is one in which the AI does the optimisation and the determinism does the safety, and neither is asked to do the other's job.

§What this is not

It is not a way of avoiding the question of AI safety. The vehicles in this system still have to make good decisions inside their own envelopes. The protocol does not relieve operators of that responsibility — it just makes sure the airspace does not depend on it.

It is not a claim that AI is unnecessary in low-altitude operations. It is the opposite. The protocol is designed around the expectation that AI will be doing meaningful work in every vehicle, and that the volume and complexity of that work will increase. The protocol's job is to make sure that work is bounded by clear interfaces and falls back to safety when it fails.

It is not a claim about which AI techniques will win. The protocol is studiously neutral on that question. A vehicle that uses 1995-era constraint solvers and one that uses 2025-era foundation models are equally welcome, as long as both speak AACP and honour the fallback.

§Where the hard work actually is

The hard part of building AACP-compliant vehicles is, in my experience, neither the AI nor the geometry. It is the trust layer — the part where vehicles must decide how much to believe each other.

A naive implementation either trusts every broadcast equally (vulnerable to malicious or buggy participants) or trusts nothing (effectively reducing the airspace to single-vehicle operation). The interesting middle is a reputation system that is itself robust against the failure modes it is supposed to protect against: Sybil attacks, collusion rings, slow-burn reputation manipulation, false-positive bans of legitimate operators.

The protocol describes the trust layer's required properties and its observable behaviour, but the actual implementation has substantial design freedom. Different operators may run different reputation models against the same protocol stream. This is intentional. It is also a topic for another post, after I have spent some more time writing the parts of the implementation that exist.

§What comes next

This concludes the first three-post arc — altitude as information, hex cells as substrate, and AACP as the communication layer. The next arc will be more concrete and more practical: how the protocol is being implemented, what the reference codebase looks like, where the implementation has surprised me, and what parts of the original design have already been revised in contact with code.

If the abstract layer has felt less satisfying than the concrete one will, that is normal. The protocol exists in the abstract because that is the only level at which it can be invariant across hardware, vendor, and decade. The code that implements it is allowed to be opinionated. The protocol itself cannot afford to be.