TL;DR: If you decomposed every ATC function on a typical IFR flight and asked which ones genuinely require a human, the answer is more provocative than most people expect. The substantial majority of routine communication is structured data delivery — frequency changes, altimeter settings, position reports — routed through a human because no alternative was ever built. But it goes deeper than communication. Sequencing is an optimization problem with structured inputs, and the FAA’s own Time-Based Flow Management (TBFM) already computes the answers — controllers at equipped facilities are relaying algorithm output via voice rather than delivering it directly to the cockpit. What remains irreducibly human — reading a distressed pilot, reasoning through a novel situation, being a calm voice during an emergency — is worth preserving, and worth designing around. The barrier to change is not technical. It is institutional.

---

On a clear afternoon last spring, I was flying N117ZS — my Sling TSi — from Los Angeles to Seattle on an IFR flight plan. The skies were smooth, the avionics were humming, and the workload was manageable. The radio, however, told a different story.

Frequency change after frequency change. Altimeter setting after altimeter setting. Routine, repetitive, structured exchanges that consumed a significant portion of every sector handoff. And occasionally — not always, but enough to notice — communications that were rushed, stepped on, or simply hard to parse. Nothing unsafe. Just a system clearly straining under its own weight — routing structured data and computed decisions through a human because no alternative was ever built.

That flight got me thinking about a question that sounds radical until you actually examine it: how much of what air traffic controllers do today could be done better by a different Air Traffic Control (ATC) paradigm?

This post is an attempt to follow that question without flinching from the institutional conclusions it points toward.

A note on perspective: I’m a GA pilot, a commercial air traveler, and a technologist. I’m not an air traffic controller or an aviation regulator — but I’ve spent enough time in the system, and enough time thinking about how complex systems fail and improve, to ask some uncomfortable questions about it.

Section 1: A System Under Stress

The Numbers Are Not Good

The U.S. air traffic control system is understaffed, under-equipped, and operating on infrastructure that in some cases predates the aircraft it manages. This is not hyperbole — it is the documented conclusion of the FAA’s own operational risk assessment, the Government Accountability Office, and the Department of Transportation’s Inspector General.

As of late 2024, the FAA employed approximately 10,800 fully certified controllers against an identified operational need of roughly 13,400 — a structural deficit of more than 2,500 positions that has persisted for over a decade. [source] Over 40% of the FAA’s 290 terminal facilities were operating below their own staffing targets as of September 2024. [source]

The pipeline meant to close that gap is, by one expert’s description, mathematically broken. Only about 2% of applicants ultimately become certified professional controllers — a figure confirmed by the GAO’s own analysis of more than 100,000 applications. The process from application to certification can take up to six years. The FAA achieved a net gain of just 15 certified controllers in fiscal year 2023, and 108 in 2024 — despite meeting its hiring targets both years. [source] Hiring and attrition are nearly canceling each other out.

Meanwhile, a 2024 GAO report found that 51 of the FAA’s 138 air traffic control systems are classified as unsustainable — some more than 30 years old, lacking modernization plans, running on infrastructure that belongs in a different century. [source]

The Communication Layer Is From a Different Era

Underneath all of it — the radar, the automation tools, the decision support systems — the primary communication channel between controllers and pilots remains VHF radio. A technology developed in the 1930s. Voice transmissions on shared frequencies, one speaker at a time, parsed by human ears under noise and workload, read back by human voices, and confirmed by human judgment. Your glass cockpit talks to satellites. Your autopilot flies precision approaches to within feet. And then the controller calls with your altimeter setting on a radio protocol that predates the transistor.

This is not a minor implementation detail. The entire coordination layer of the National Airspace System (NAS) — the mechanism by which instructions are issued, acknowledged, and executed — runs on voice over VHF. Every inefficiency, every miscommunication, every readback error in this post flows from that single architectural fact.

The Consequences Are Not Hypothetical

The January 2025 collision at Reagan National Airport — 67 fatalities — brought these numbers into sharp relief. Investigators identified that the controller on duty was simultaneously managing helicopter routes and fixed-wing traffic because there were not enough controllers to staff each position independently. [source] One human. Two jobs. One frequency. Sixty-seven people gone.

It was not an anomaly. A NASA Aviation Safety Reporting System survey found that one third of general aviation incidents involve communications difficulties. [source] Readback errors on a single frequency occur close to one per hour across ATC environments, with high controller workload and similar callsigns among the most common contributing factors. [source] The system is not failing because the people in it are inadequate. It was designed in an era when computers didn’t exist, and it hasn’t been fundamentally redesigned since.

A Narrow Scope — and an Explicit One

Before going further, a boundary condition: this exploration is technical and economic. It does not address labor relations, union considerations, or the long-term trajectory of artificial intelligence in human communication roles. Those are legitimate topics for other discussions. What follows is a narrower question — given the technology that exists or is demonstrably close, what ATC functions could be handled differently, what would that require in the airplane and on the ground, and what would it cost?

The answer is more provocative than you might expect.

---

Section 2: What ATC Actually Does

Before asking what could change, it’s worth being precise about what ATC actually does. Not the job title, not the facility, not the staffing model — the function. What work is actually being performed on that frequency?

Broken down to its components, ATC has four distinct jobs:

Separation — keeping aircraft away from each other and from terrain. This is the foundational safety function. Given position, altitude, speed, and flight plan, a conflict is identified and resolved through altitude assignments, vectors, or speed adjustments.

Sequencing — getting aircraft to the right place at the right time. Managing the flow of arrivals into a terminal area, merging traffic onto a final approach course, spacing departures off a runway. This is an optimization problem with constraints.

Information — delivering data the pilot needs. Weather, NOTAMs, altimeter settings, traffic advisories, field conditions. The controller as a real-time information relay.

Coordination — handoffs between sectors and facilities. The procedural transfer of responsibility as an aircraft moves through the system. Approach to tower. Center to TRACON. Sector to sector.

These four functions look unified from the cockpit because they arrive through the same channel — a voice on a VHF frequency. But they are architecturally distinct. And that distinction matters enormously when you ask which of them requires a human.

A Flight Through the System

To make this concrete, consider what a typical IFR flight actually generates in terms of ATC communication. On the LAX to Seattle ferry flight that opened this piece, the exchanges fell into a predictable pattern.

Departure: clearance readback, taxi instructions, takeoff clearance. Climb out: initial frequency change, departure instructions, altitude assignments. Enroute: sector handoffs every twenty to forty minutes, each consisting of a frequency change and a new altimeter setting. Occasionally a traffic advisory, a ride report request, a routing amendment. Arrival: ATIS retrieval, initial contact with approach, altitude stepdowns, speed adjustments, approach clearance, tower handoff, landing clearance.

Count the exchanges. A four hour IFR flight might generate forty to sixty discrete ATC communications. The majority of them are structured, predictable, and informationally simple. Frequency change. New altimeter. Descend and maintain. Contact approach on 124.5. By the time the controller picks up the microphone, the system already knows your position, the sector boundary, and that the handoff has been coordinated. The voice call is a notification of something the system already decided.

The Readback Loop

The readback requirement deserves specific attention because it is both essential and expensive.

Readback exists because VHF voice is an unreliable channel. Stepped-on transmissions, background noise, accent and dialect variation, frequency congestion, and simple human error all create the possibility that an instruction is misheard. The readback is a checksum — a confirmation that what was received matches what was sent.

It works. And it consumes an enormous amount of frequency time doing it. Every instruction requires two transmissions — the issuance and the confirmation. On a busy frequency, the channel is occupied for the readback of one aircraft while three others are waiting to make initial contact. The inefficiency is not incidental. It is structural, and it is a direct consequence of using voice as the primary data channel.

A structured datalink message has an implicit readback built in. The message is either received and acknowledged or it isn’t. There is no ambiguity, no misparse, no stepped-on transmission. The confirmation is binary and automatic. The channel is freed immediately.

What LiveATC Tells You

If you have never spent time listening to a busy TRACON frequency, LiveATC.net is an education. SoCal Approach. New York Center. Chicago O’Hare ground. Pick a busy facility during push hours and listen for ten minutes.

What you will hear is a controller working at the edge of cognitive capacity — issuing instructions, confirming readbacks, managing conflicts, handling requests, all on a single shared channel, all in real time, all via voice. You will also hear the inefficiency in raw form: the stepped-on calls, the “say again,” the phonetic spelling of a waypoint that took four seconds to deliver and four more to read back. It is impressive human performance. It is also a fragile system running near its limits by design.

---

Section 3: What Could Be Done Differently

With the four functions mapped and a typical IFR flight in mind, the question becomes tractable. if we were designing the airspace communication and management system from scratch today, which functions would we assign to a different architecture, and which would genuinely require a human?

It helps to draw a distinction up front. Some functions are data delivery problems — the information already exists in the system, and voice is simply a redundant, error-prone mechanism for transmitting it. Others are decision problems — someone or something has to compute an answer before anything is delivered. Both categories turn out to have strong cases for a different approach, but for different reasons.

Data Delivery: The Information Already Exists

Frequency changes. The system maintains continuous awareness of every aircraft’s position through multiple independent means — radar, transponder returns, and position reporting technologies. It knows the sector boundaries. The handoff between facilities has already been coordinated electronically before the controller keys the mic. The only remaining act is notifying the pilot which frequency to dial. In Europe, Controller Pilot Data Link Communications (CPDLC)-equipped facilities already handle this automatically — when the controller accepts a handoff, the system sends the new frequency directly to the cockpit. [source] The voice call is not adding information. It is delivering a notification that the system has already generated.

Altimeter settings. Current altimeter settings are published continuously by every major weather reporting station. The data exists, it flows, and it already reaches the cockpit through multiple digital channels. The voice exchange — “altimeter 29.92” — is a legacy interface to information the system already has. In a system designed today, the current setting updates on the flight display automatically as the aircraft transitions regions. The controller was never adding analytical value to this transaction — only delivering it.

Position reports. The system already knows where every aircraft is through continuous, redundant position awareness. The formal position report call is a holdover from an era when ground-based awareness was incomplete and pilots were the primary means of maintaining the system’s picture. In a modern environment, the position report is ceremonial. It can be retired — not as a policy proposal, but as a logical consequence of the system already having the information.

Routine traffic advisories. “Traffic, two o’clock, five miles, eastbound, altitude indicates 8,500.” This call exists because the pilot may not have the traffic on their display. In a well-equipped cockpit, they already do. In a system designed today, the ground system verifies that the pilot’s avionics have received and are displaying the relevant traffic. If they are, no advisory is needed. If they aren’t — equipment gap, non-transponding traffic, display failure — the system flags for human attention.

ATIS and weather delivery. Automated Terminal Information Service is already automated in name. The information exists in structured digital form before any pilot asks for it. The remaining friction is the ritual of manually retrieving it and confirming receipt verbally on initial contact. In a system designed today, current ATIS and relevant weather data is pushed to the cockpit as the aircraft enters the terminal area. The “have information Foxtrot” call disappears because the system already knows you have it.

Decision Automation: The Computation Is Already Happening

Sequencing. Sequencing — merging arrivals, assigning speed adjustments, building the flow to the runway threshold — looks like human judgment. But examine what the decision actually requires: aircraft positions, speeds, performance envelopes, runway assignments, weather constraints, wake turbulence categories, and an optimization objective. Every one of those inputs is structured data. The output is the solution to a constrained optimization problem.

The FAA already knows this. Time Based Flow Management — TBFM — is a computerized decision support tool deployed at major facilities that schedules aircraft within a traffic stream to reach defined constraint points at specified times. [source] Its Terminal Sequencing and Spacing extension — TSAS — provides controllers with computer-generated speed advisories to maintain a predetermined arrival sequence. At facilities where TBFM and TSAS are deployed, controllers are already relaying computer-generated advisories to pilots via voice. The sequencing computation is already happening. The question is whether the human relay between algorithm output and cockpit is necessary — or whether datalink closes that gap directly.

Approach assignment. A runway designation, a procedure type, a transition name — three discrete data fields. In a system designed today, that message arrives on the cockpit display, the navigator loads the approach, and the pilot confirms. The FAA’s DataComm program has demonstrated this in commercial aviation: departure clearances via CPDLC have been operational at dozens of domestic facilities since 2016, enroute datalink since 2019, now covering more than 65 facilities. In those facilities, this is not a thought experiment. It is the operational reality.

What the Evidence Actually Shows

The FAA’s own DataComm program — already operational at 65 domestic facilities — has saved over 2.1 million minutes of radio time between controllers and pilots, prevented more than 123,000 readback errors, and saved over 1.4 million minutes of airspace user time in the terminal environment alone. [source: FAA Office of Communications] These are not projections. They are measured outcomes from a partial deployment. The full-flight picture involves the same structured, data-delivery exchanges that DataComm already handles where deployed — and the substantial majority of routine IFR communication falls into that category.

The residual is not trivial. It is the weather deviation request, the non-standard situation, the ambiguous transmission, the emergency. It is the work that benefits most from undivided human attention — and that attention becomes available precisely because the routine majority is no longer competing for it.

---

Section 4: What Requires a Human

The case for a different architecture is strong. But intellectual honesty requires an equally rigorous look at the other side. What does a human controller do that a system designed today could not? The answer is narrower than the current staffing model implies — but it is real, and it matters.

The Controller as Accidental Psychologist

Consider what happens when a pilot’s voice changes on the frequency.

Not the words. The voice. The slight compression in the transmission. The half-second pause before a readback that should be immediate. The overcorrection in diction from a pilot who is working hard to sound calm. Experienced controllers notice these things. They are not in the ATC handbook. They are not a defined procedure. They are pattern recognition built from thousands of hours of listening to humans under stress.

Call it what it is: the controller is functioning as an accidental psychologist. It is not in the job description. It is not what the training emphasizes. But it is arguably the most valuable thing a human brings to the frequency — and it is the function least amenable to replacement with current technology.

The Genuinely Novel Situation

Beyond the psychological dimension, there is a category of operational situation that falls outside any defined parameter set. Not the ad hoc approach sequence — that is a UI problem, as we established. Not the weather deviation — that is a structured request with known resolution paths. The genuinely novel situation is the one that hasn’t been categorized yet.

The aircraft that declares it has a problem but can’t describe what the problem is. The pilot who is clearly disoriented but not declaring an emergency. The situation where two separate anomalies converge in a way the system hasn’t seen before. These are not common. But they are the moments where a human’s ability to reason from first principles — to ask “what is actually happening here” rather than “which rule applies” — is irreplaceable with current tools. They are the long tail of the risk distribution, and they justify human presence in the system.

The Emergency Communication Role

When a pilot declares an emergency, the operational response — clear the airspace, compute vectors to the nearest suitable runway, alert crash and fire rescue, notify downstream facilities — is largely computable. A system designed today executes those functions faster and more accurately than a human under the same pressure. What the system cannot do is be a calm human voice on the frequency.

A pilot in a genuine emergency — partial systems, deteriorating situation, possibly an inexperienced pilot or a non-pilot passenger who has taken the controls — does not need an automated acknowledgment. They need to hear a person. Someone who will stay on the frequency, respond in plain language, adapt to what they are actually saying rather than what the system expects them to say, and provide the psychological anchor that keeps a deteriorating situation from becoming a fatal one.

The current system recognizes this, at least in principle. Standard procedure calls for a dedicated controller to be assigned to the emergency aircraft — someone who can focus entirely on that flight while others absorb the surrounding traffic. [source: Boldmethod] The problem is the qualifier: if staffing allows. Under the staffing conditions documented in Section 1, the backstop frequently isn’t available. And when an emergency is declared, the automated processes that normally support the controller largely disappear, replaced by manual coordination — the system regresses at precisely the moment it should step forward.

The Design Failure Hidden in Plain Sight

The current system asks the same person to perform the accidental psychologist function and the traffic computation function simultaneously — and ensures they compete for the same attention at exactly the wrong moment. An architecture that separates the computational functions from the human communication functions doesn’t just make the system more efficient. It makes the human role more effective. The controller reserved for exception handling and emergency communication is not a lesser version of today’s controller. They are a specialist — with undivided attention, available for exactly the moments that require a human.

The Honest Summary

The human residual in ATC is not the traffic management. It is not the data delivery. It is not even most of the decision-making. It is this: the ability to read another human being through a radio channel. The capacity to reason from first principles in a genuinely novel situation. The presence of a calm human voice when another human is in danger. Those are worth preserving — and worth designing around, rather than burying inside a system that treats them as incidental to the job of telling pilots their altimeter setting.

---

Section 5: The Technology in the Airplane

The previous sections established what could theoretically be done differently. This section asks a more practical question: what does the airplane need to participate in that architecture, and does the hardware exist? The answer is closer than most people expect. In many cases it is already there.

The Foundation: Position and State Awareness

Any automated ATC architecture begins with one requirement — the ground system must know where every aircraft is, continuously and accurately. This is already largely solved through two overlapping systems. Radar — primary and secondary — has provided the backbone of NAS position awareness for decades and remains the primary surveillance layer at major facilities. ADS-B Out, mandatory in most controlled airspace since January 2020, adds GPS-derived position, altitude, groundspeed, track, and identity broadcast at one-second intervals, significantly enhancing accuracy and coverage. Together they give the system a continuous, high-fidelity picture of equipped aircraft across most of the NAS.

Gaps remain in remote and low-altitude areas — parts of Alaska, mountainous terrain, corridors away from major ADS-B ground receiver infrastructure. Ironically, this is where the satellite architecture is strongest. ADS-C — Automatic Dependent Surveillance-Contract, already operational in oceanic airspace — has the aircraft’s own FMS push position, altitude, speed, and projected flight path directly to the ground system via satellite. No ground receiver needed. The same satellite terminal that carries CPDLC instructions to the cockpit carries surveillance data back to the ground. In the areas the current system covers least well, the satellite architecture requires no additional infrastructure at all.

ADS-B In: The Cockpit Already Knows

ADS-B Out is one side of the equation. ADS-B In is the other — and it is equally relevant to this argument. It receives traffic and weather data broadcast by other aircraft and ground stations, displaying it on the cockpit display or EFB in real time. It is not mandated, but it is widely adopted — and the hardware has become remarkably capable and remarkably affordable.

The portable ADS-B market demonstrated something important: the technology cost of a multi-function avionics datalink device is low. A Sentry Plus delivers ADS-B In traffic, GPS, AHRS, and SiriusXM weather for under $700. A Stratus 3 delivers ADS-B In for under $900. These devices connect to any EFB via Bluetooth, work with any avionics stack, and require no permanent installation. They establish a proven product category: a portable, multi-function avionics datalink device at GA price points, delivering real-time data to the cockpit without certified installation. Adding a satellite ATC instruction channel to that same device architecture is an incremental step, not a new invention.

The Missing Piece: Two-Way Datalink

ADS-B Out broadcasts position from the airplane. ADS-B In receives traffic and weather from the ground network. What an automated ATC architecture additionally requires is a two-way pipe for structured ATC instructions: the ground system needs to push clearances and advisories to the cockpit, and the cockpit needs to send structured requests and acknowledgments back. This is the gap. Not a large one technically. But it is the gap.

Why Satellite Beats Ground Infrastructure

The conventional model for aviation datalink — VHF Data Link, or VDL Mode 2 — requires a network of ground stations with line-of-sight coverage to aircraft. Building that network to cover the entire NAS at low altitude is a capital construction project of the kind the FAA has consistently failed to deliver on time and on budget. NextGen — the FAA’s decade-long modernization program — cost tens of billions of dollars and remains incomplete.

Satellite datalink inverts the model entirely. The infrastructure already exists above the entire NAS simultaneously. Coverage is uniform from takeoff to landing, including oceanic airspace and anywhere a VHF ground network would struggle to reach. Scaling doesn’t require new construction — it is a software and spectrum problem, not a civil engineering one.

The two most relevant options today are Iridium Certus and Starlink Aviation. Iridium Certus operates on a constellation of 66 satellites at approximately 781 kilometers altitude — low enough that a purpose-built aviation datalink terminal achieves approximately 0.5 second latency in practice, well within the operational window for any non-emergency ATC exchange. Iridium is launching Certus AvSafety in 2026 — a safety-certified service explicitly enabling ADS-C and CPDLC over satellite, retrofittable across a range of cockpits. Starlink Aviation operates at approximately 550 kilometers altitude and achieves latencies of under 30 milliseconds. It has been certified and flying on commercial aircraft since Hawaiian Airlines became the first major US carrier to deploy it in February 2024.

A critical clarification on latency: the 10-30 second delays associated with consumer satellite devices like the Garmin inReach are not a physics constraint. They are an artifact of hardware optimized for low power consumption and hiking trails, not for operational aviation communication. The Garmin inReach Mini retails for around $200. That is the price floor. Iridium Certus and Starlink demonstrate the performance ceiling. A purpose-built aviation datalink terminal sits between those two points in both cost and performance.

CPDLC: The Protocol Is Already Standardized

The communication pipe is one problem. The message format is another. And here, the answer is already settled. Controller Pilot Data Link Communications — CPDLC — is a defined message set for structured air-ground communication covering altitude clearances, routing amendments, frequency changes, weather deviations, speed adjustments, approach assignments, and pilot requests. The messages are discrete, structured, and unambiguous. No parsing problem, no readback ambiguity, no stepped-on transmission.

CPDLC already operates in oceanic airspace worldwide and at more than 65 domestic enroute facilities in the US. The protocol is not experimental. It is operational. And it is transport-agnostic — running CPDLC over Iridium Certus or Starlink requires no changes to the message standard, only a different radio on each end. The protocol work is done. The satellite infrastructure exists. What is missing is a low-cost terminal that brings the GA fleet into the datalink ecosystem.

The Cockpit Integration Model

A satellite datalink terminal is only as useful as its integration with the cockpit systems that act on its messages. The integration principle is straightforward and not specific to any one avionics manufacturer: a CPDLC message arrives via satellite datalink, is displayed on the primary cockpit interface, the pilot confirms with a single input, and the avionics execute. A routing amendment loads into the active flight plan. An approach assignment populates the approach page. An altitude clearance pre-selects on the autopilot.

This model works across avionics ecosystems. Garmin’s Connext architecture — connecting the G3X, GTN, GFC 500, and Garmin Pilot via wireless data sharing — is one implementation. Dynon’s SkyView ecosystem, Avidyne’s IFD series, and ForeFlight running on any compatible hardware are others. The message format is standardized. Any modern glass cockpit or EFB-based panel has the display and confirmation capability already. What none of them currently have is the upstream satellite datalink feed. The portable device market is the natural entry point — the same Bluetooth connectivity that delivers ADS-B traffic and weather from a Sentry or Stratus could deliver CPDLC messages from a satellite datalink terminal to the same display.

The Cost Picture

The ADS-B mandate is the instructive precedent. When announced, certified installed ADS-B Out hardware ran $3,000 to $6,000. The portable market demonstrated that the underlying technology cost was a fraction of that. A Sentry today delivers full ADS-B In, GPS, AHRS, and Bluetooth connectivity for under $700.

The satellite datalink parallel is direct. A Garmin inReach Mini — a full two-way satellite communicator on the Iridium network — costs around $200. It demonstrates that the core hardware — satellite radio, processor, protocol stack, Bluetooth — costs roughly $200 at consumer volumes. A purpose-built aviation satellite datalink terminal would cost more than an inReach Mini and less than current certified CPDLC hardware. At volume, with competition, the GA price point is a few hundred dollars. The per-aircraft cost of participating in a satellite-based automated ATC architecture, at scale: likely under $500 in hardware.

What Is Actually Missing

The position awareness foundation is already there — ADS-B Out is flying and the FAA’s ground receiver network is built. The cockpit display and confirmation capability is already there — ADS-B In devices in thousands of cockpits demonstrate the product category at accessible price points. The message protocol is already standardized — CPDLC is operational in commercial aviation. The satellite infrastructure is already deployed — Iridium and Starlink cover the NAS completely.

What is missing is the link between them: a portable, affordable satellite datalink terminal that receives CPDLC messages from a ground automation system and delivers them into the cockpit ecosystem. ADS-B demonstrated that the GA market will equip voluntarily when the device is capable, affordable, and the value proposition is clear. The satellite datalink terminal is the next device in that lineage — not a research project, but a product development and certification problem of the kind this market has solved repeatedly.

The airplane is closer to ready than the ground system is.

---

Section 6: What the FAA Needs to Build

The airplane side of this architecture is largely ready. The ground side is not. But “not ready” and “impossibly far” are different things. The architecture has four layers — independent enough to be built incrementally, interdependent enough that each one enables the next.

Layer 1: The Communication Layer

The pipe between aircraft and ground system. Everything else depends on it. The FAA’s role here is not to build infrastructure — it is to contract for a service that already exists, define the airborne terminal specification, and mandate or incentivize equipage. This is a procurement and standards problem, not a construction problem. The FAA already does this for GPS — it leverages a satellite constellation it didn’t build and defines the aviation use cases on top of it. The ADS-B mandate is the template: announce the requirement, set a compliance date, let competition drive hardware costs down.

Layer 2: The State Layer

A continuous, complete, trusted picture of every aircraft in the NAS — not just position, but intent. Position is already largely solved. ADS-B Out gives the system continuous location data; radar fills gaps. What is largely missing is intent data — where the aircraft is going, not just where it is. Filed flight plans provide a static snapshot that doesn’t reflect amendments, deviations, or the dynamic evolution of a flight in progress.

The technology for intent sharing exists. In commercial aviation, ADS-C — Automatic Dependent Surveillance-Contract — continuously downlinks position, altitude, speed, and projected flight path from the aircraft FMS to the ground system. It is already operational in oceanic airspace. Extending ADS-C to domestic GA aircraft, via the same satellite datalink terminal that carries CPDLC, closes the intent gap without a separate infrastructure problem.

Layer 3: The Computation Layer

The automation engine. Significant pieces already exist: TBFM handles enroute flow management, TSAS is being deployed for terminal sequencing, STARS handles radar display and conflict detection at TRACON facilities, and ERAM handles center-level automation. The honest assessment: these systems were built incrementally by different contractors over different decades and do not constitute a unified architecture. They are islands of automation connected by manual coordination. The human controller is often the integration layer between them.

A system designed today would require a unified computation layer that ingests continuous position and intent data, runs separation assurance continuously, generates sequencing advisories NAS-wide, processes structured pilot requests, and flags exceptions for human review. The algorithms for this are well-developed in research. MITRE’s Center for Advanced Aviation System Development has published extensively on automated separation assurance. [source: MITRE CAASD] What has not happened is productionizing it into an operational system.

Layer 4: The Human Interface Layer

Where humans plug back into the system — not as primary operators, but as supervisors, exception handlers, and emergency communicators. This layer has two components. The first is the exception console — the interface through which flagged situations are presented to human controllers for review and intervention. The second is the emergency communication station — a dedicated voice channel for human-to-pilot communication in emergencies and non-standard situations, staffed by controllers who are not simultaneously managing routine traffic.

The design of these interfaces matters enormously. The failure mode of automation systems in safety-critical domains is frequently not the algorithm — it is the human interface. Controllers who don’t trust the system, who override it reflexively, who lose situational awareness because the automation handles the routine: these are real risks that interface design must address directly.

The Transition Path

A credible transition does not require building everything at once. Each phase delivers independent value and is reversible if problems emerge.

The Satellite Dependency Risk

One objection worth addressing directly: satellite infrastructure introduces a single point of failure risk. The answer is redundancy and graceful degradation, not avoidance. Voice VHF remains available as a backup at every phase of the transition — a satellite outage reverts the system to current operations, not to failure. A hybrid architecture — satellite primary, VHF datalink secondary at major terminal areas, cellular as a tertiary layer below 10,000 feet — provides resilience without a single point of failure.

---

Section 7: Where This Line of Thinking Leads

The case is not speculative. The FAA’s own DataComm program — a partial deployment — has already saved over 2.1 million minutes of radio time and prevented more than 123,000 readback errors. [source: FAA Office of Communications] That is the measured outcome of deploying datalink for a subset of exchanges at a subset of facilities. The substantial majority of routine IFR communication shares the same structured, computable characteristics as the exchanges DataComm already handles. The missing piece on the airplane side — a portable, affordable satellite datalink terminal — is a product development problem, not a research problem. The ground side requires systems integration and procurement, not invention.

The Traffic Argument

There is a dimension to this that goes beyond efficiency or safety improvement. The NAS faces a structural volume problem that the current architecture cannot solve — not with more controllers, not with incremental modernization, not with any amount of NextGen spending. Commercial aviation traffic is projected to double by the early 2040s. [source: ACI World / ICAO Joint Passenger Traffic Report] Urban air mobility — eVTOLs operating in low-altitude urban corridors — represents an entirely new traffic category that doesn’t fit existing airspace management models. Drone operations are already forcing the FAA to build parallel automated traffic management infrastructure because voice-based ATC is physically incapable of handling the volume — the FAA’s own UTM program exists precisely because no alternative exists, with eight eVTOL integration pilot projects already selected across 26 states as of March 2026, putting pre-certified electric aircraft into Class B and C airspace alongside conventional traffic.

These aren’t future problems. Drone beyond-visual-line-of-sight operations are being approved now. eVTOL certification programs are active at multiple manufacturers. The airspace of 2030 will carry traffic categories and volumes that the 1950s architecture was never designed for and cannot accommodate. The question is not whether to change. It’s whether to change deliberately or to wait until the system fails to scale and forces the change under worse conditions.

The Barrier Is Not Technology

The staffing crisis is real. The infrastructure is aging. The communication layer is a 1930s technology running a 2025 airspace. The accidents that result from these failures are documented, numbered, and named. The technology to address the structural problem exists. The cost model is viable. The transition path is incremental and reversible. What is missing is the institutional decision to build what the evidence points toward — and to design the system around what it actually needs rather than around what it has always been. That is not a technology problem. It is a harder one.

A Final Observation

On that LAX to Seattle flight, somewhere over Northern California, I was handed off to a new sector. The controller came on frequency, gave me a new altimeter setting, told me to contact the next sector on a new frequency, and signed off.

Three pieces of information. Two of them were already in the system before he picked up the mic. The third was the output of a handoff already coordinated electronically. That exchange happened about a dozen times before I landed.

None of it required a human. All of it consumed one.