Airport slots and the missing right to transfer compute

A reservation is not necessarily an asset that its holder can sell. That distinction matters before a secondary market for unused GPU capacity can operate. A buyer can pay for a precisely specified machine and time window yet lack permission to transfer that booking. The practical implication is to classify contractual rights before comparing prices. Airport slots offer a useful historical analogy: scarcity existed before an organized transfer mechanism, but trading depended on rules defining who could hold a slot and how an assignment became valid.

What the airport market actually created

The FAA defines an airport slot as authorization for a planned takeoff or landing at a particular airport, day and time. It is distinct from air traffic control clearance. Holding the scheduling right does not itself authorize the aircraft’s immediate movement. This separation between advance allocation and operational execution is the first useful lesson for compute. A reservation, a successful instance launch and a completed workload are different events. FAA slot definition, updated April 24, 2020.

The US Department of Transportation’s December 20, 1985 rule allowed purchases, sales and leases of specified airport slots beginning April 1, 1986, subject to restrictions. The rule required transfer documentation and FAA confirmation before a recipient could use the slot. It also explained that the delayed start allowed a tracking system to be established. These were not peripheral administrative details: a buyer needed confidence that the seller’s right existed and that the authority recognized the new holder. Original final rule, excerpt.

There is an important historical qualification. The original rule used a 65 percent utilization threshold over two months. The FAA’s later general overview describes an 80 percent requirement and explicitly allows waivers. Neither figure should be transplanted into a GPU contract, nor should the overview be treated as a complete statement of today’s airport-specific exceptions. The relevant institutional idea is that a transfer right can coexist with conditions governing retention and use. FAA compliance overview, updated February 1, 2021.

The compute contrast

AWS Capacity Blocks provide a concrete counterexample to the assumption that advance reservations are freely tradable. The documentation describes offerings with a start time, Availability Zone and reservation price. It also distinguishes the reservation’s end from the usable operating window: termination begins during the final 30 minutes for instance types or 60 minutes for UltraServers. A procurement system must preserve that distinction when checking deadlines. AWS Capacity Blocks documentation, accessed November 6, 2026.

More decisively, section 5.5.2 of the AWS Service Terms says Capacity Blocks are nontransferable, cannot be resold, and are nonrefundable. It also prohibits submitting Capacity Block requests through a third party, including proxy purchasing. These terms do not establish the policy for every compute provider. They do establish that a broker cannot presume permission to buy these blocks for onward resale or execute purchases as a proxy. AWS Service Terms, page last updated November 5, 2026.

The market-design inference is narrow but consequential. A quotation system should identify separately the customer, the permitted purchaser, the holder of the reservation, and the party operating the workload. A provider-approved arrangement might eventually connect those roles differently. An attractive spread alone cannot establish that arrangement. For this product, recommendations and customer-controlled purchasing are a safer starting point than assuming a universal execution adapter.

A worked decision about flexibility

Consider an entirely hypothetical procurement decision. An experimental workload has a 70 percent chance of being ready on Monday. If ready, it needs a tested configuration for a fixed window. Two suppliers offer technically equivalent capacity, with identical operating costs and performance. Supplier A charges $10,000 immediately, with no cancellation refund. Supplier B charges $11,000 but expressly permits cancellation before Sunday for a $1,000 fee. These are invented contracts, not AWS quotations.

If readiness is confirmed before the cancellation deadline, expected reservation expenditure is $10,000 under A. Under B it is 70 percent of $11,000 plus 30 percent of $1,000, or $8,000. B’s higher headline price buys an exit right that reduces expected expenditure by $2,000 in this example. The break-even readiness probability is 90 percent: above that, A becomes cheaper on these assumptions.

This calculation values cancellation, not speculative resale. Suppose someone instead advertises a $4,000 recovery from selling A’s unused booking. That credit belongs in the calculation only after transfer permission, a feasible process and credible buyer demand are established. A prohibited transfer has no legitimate resale value. Even a permitted transfer may fail to find a buyer before the window expires.

The recommendation should therefore expose its assumptions: equivalent usable capacity, readiness known by the deadline, the stated cancellation fee and no additional migration cost. It must also show the downside: if the workload is ready, B costs $1,000 more. Expected savings do not remove that possible outcome.

Why the analogy has limits

Airport slots concern access to congested public infrastructure under regulatory authority. Compute reservations are generally contractual claims on services operated by suppliers. No single compute regulator plays the FAA’s role across clouds. Machines can also differ in memory, networking and software compatibility. Permission to transfer a reservation would not make those differences disappear.

The analogy supplies a design question, not proof that a secondary exchange will be efficient. Providers may reasonably restrict transfers to preserve customer screening, capacity planning or product segmentation. An intermediary can add fees and operational ambiguity. If providers already reallocate released capacity cheaply, a separate exchange might duplicate an existing function rather than improve it. Whether buyers would pay enough for independent transferability remains an empirical question.

A utilization rule also deserves skepticism. Requiring customers to run work merely to retain future access could reward waste. A compute market should investigate release incentives and explicit cancellation terms before borrowing aviation’s use-or-lose mechanism.

What PCT should implement first

The immediate institution is a rights register attached to each quote: who may purchase, whether cancellation or transfer is permitted, the cutoff time, usable service interval, and the evidence needed for execution. Human approval should cover the actual commitment and exit restrictions. The receipt should connect the accepted quote, provider confirmation and service delivered, without implying that a payment receipt proves workload success.

This approach advances the full requirements-to-receipt workflow while admitting that some products stop at recommendation and customer execution. The open research questions are measurable: how frequently do bookings become unnecessary, how early is that known, what recovery do authorized cancellations achieve, and which suppliers permit reassignment? Until those answers exist, transferability is a contract feature to verify and value, not liquidity to assume.