That sounds suspiciously like an AI prompt. I rephrased it slightly as:
I am thinking that the current system is not optimal, but it's here based on accumulation of different parts and rules that made the most sense at the time. You are an FAA official tasked with creating an airspace system from scratch. Let's say that you have a clean slate, there are no victor airways, no class A/B/C/D airspace designations, no VORs or ILS (although those technologies exist).Your task is to create, from scratch:
- The airspace- Navaids (place VOR's, ILSs... wherever you'd like)
- Approach/departure procedures
- En route rules
- Training rules for IFR flying
- Aircraft equipment that you would need/want to fly IFR
What it came up with looked a lot like the existing system. However, there were a few differences. The full text is way too long to copy/paste verbatim so I'll try to hit the highlights and edit/paraphrase as best I can for brevity.
-------------------------
Below is a clean-sheet IFR system design—my proposal, not a description of current FAA policy. I’m using today’s published FAA/ICAO principles as the starting point: a modern system should be PBN-first (RNAV/RNP), because FAA guidance says RNAV/RNP allows aircraft to fly desired paths, can reduce vectoring and radio traffic, and can improve airspace efficiency; RNP specifically adds onboard performance monitoring and alerting. Current instrument procedures are also built around standardized departure / en route / arrival / approach / missed segments, which I’d keep in spirit even if I redesign the structure.
1) Design philosophy: what problem are we solving?
If I were rebuilding IFR from scratch, I would optimize for five things:
Trajectory predictability – ATC and pilots should be talking in terms of 4D trajectories (path + altitude + time windows), not a patchwork of airway segments and ad hoc vectors.
Navigation performance, not equipment tribalism
Graceful degradation – satellite nav should be primary, but the system must remain flyable through GNSS outages, lost comm, degraded surveillance, and partial equipment failures.
Airport access as a network problem – terminal procedures should be designed together with en route flows, not as local one-off solutions.
Competency-based IFR – pilots should be trained and checked on the kinds of failures and ambiguities that actually break IFR operations, not just on rote intercept/tracking tasks.
2) The airspace: replace “classes” with service layers
Instead of today’s Class A/B/C/D/E/G patchwork, I would create four IFR airspace service layers.
Layer 1 — Protected Surface Zone
This is the airport movement/near-airport protection envelope: runway environment, missed-approach corridors, departure funnels, and final-approach capture areas.
Layer 2 — Terminal Flow Zone
Roughly a metroplex terminal area, but redesigned around flow corridors rather than stacked shelves. Think of it as a set of “arrival tubes,” “departure tubes,” and “crossing windows” with published altitude/speed/time constraints.
Layer 3 — Free-Route En Route Zone
Above and between terminal flow zones, aircraft fly directed trajectories rather than airway-to-airway stitching. There are still preferred flows where beneficial, but the default concept is free-route IFR: file and fly optimized paths that fit traffic constraints.
Layer 4 — Remote / Contingency Zone
This covers low-density, terrain-heavy, surveillance-poor, or outage-degraded environments. Here the system becomes more conservative and more procedural.
3) Navaids: make it GNSS-primary, ground-based-resilient
A. GNSS + SBAS/augmentation as the default
B. A sparse, deliberate VOR/DME backup grid
C. De-emphasize NDB entirely
I would install:
Tier 1 airports (major airline hubs, frequent low-vis ops)
ILS or GLS on the primary runways, often both where justified
DME and robust lighting
Surface surveillance and runway-status integration
Tier 2 airports (regional / business / weather-significant)
RNAV (LPV/LNAV-VNAV-type capability where supported by augmentation)
One precision or high-integrity approach aid where weather/traffic justify it
DME if terrain or contingency routing benefits
Tier 3 airports (low volume)
Mostly satellite-based procedures
Ground aid only if terrain, obstacle environment, or strategic resilience requires it
4) Approach and departure procedures
Current FAA procedure architecture still has the right basic segments—departure, en route transition, arrival, approach, missed approach. The redesign is to make each segment flow-compatible and automation-friendly, rather than locally optimized.
Every IFR airport would have one of three departure designs:
A. Structured Flow Departure
Used at busy airports. Multiple published departure trunks are aligned to metroplex exit gates and major en route flows.
B. Obstacle-Critical Departure
Used where terrain/obstacles dominate. Strong vertical path discipline, climb gradients, and no ambiguity.
C. On-Demand Vector-Compatible Departure
Used at lower-volume airports, but still published with immediate contingency instructions so a pilot is never dependent on improvised vectors to escape obstacles safely.
All departures should be flyable:
With one-pilot high workload in IMC
With lost-comm continuity
With one major nav source degraded
I would replace many classic STARs with flow-based arrival families:
North-flow, south-flow, east-flow, west-flow families
Each family branches late, not early
Metering and crossing constraints happen upstream
Continuous descent is the default
The terminal area should feel like a merge network, not spaghetti.
For approaches, each runway end gets a procedure ladder:
Primary precision path – ILS or GLS where justified
Primary satellite path – RNAV/RNP
Contingency non-precision path – only where a real resilience case exists
Every missed should:
protect terrain without immediate tactical ATC heroics,
re-enter a known terminal delaying structure,
and be robust to comm/navigation partial failure.
5) En route rules
A. File by performance class, not “slant codes”
The clearance system should care about: lateral/vertical navigation performance, time-keeping capability, surveillance capability, contingency capability. So instead of a long equipment alphabet soup, you file a capability profile like:
NAV-P2 / SURV-S2 / TIME-T1 / CONT-C1
That is much closer to how the airspace actually uses the aircraft.
B. Default to free-route IFR
If weather and traffic allow, an aircraft should fly near-optimal city-pair routes. Airways exist only where they materially improve conflict management, terrain escape, or contingency operation.
C. Time-based metering
Busy terminal areas should meter aircraft by required times at boundary fixes, with tolerances. This reduces the need for late vectors and speed yo-yoing.
D. Lost-comms and degraded-nav should be simpler with one nationally standardized hierarchy:
Continue current protected trajectory if valid,
Otherwise join the nearest contingency route,
Otherwise proceed to nearest contingency arrival gate,
Otherwise execute a protected diversion logic.
E. Better weather integration
Major convective/reroute constructs should be published digitally into the filing/clearance system, not mainly via human translation of fragmented constraints.
6) Training rules for IFR flying
Stage 1 — Instrument control and scan
aircraft control by reference to instruments
unusual attitudes
automation basics
workload management
Stage 2 — System operation
route clearance management
terminal flow compliance
approach execution
missed approaches
reroutes, holds, and diversions
Stage 3 — Failure and ambiguity management
GNSS degradation/jamming/spoofing response
partial panel and display loss
unreliable ADC/AHRS cases
automation mode confusion
data-link/voice mismatch
single-pilot task saturation
weather escape decision-making
Recurrent training - Not just “six approaches.” I would require periodic demonstration in four buckets:
Precision path tracking
Trajectory changes under workload
Failure management
Decision quality / threat management
Rating structure
Basic IFR – non-high-density terminal ops, lower-performance airspace
Full IFR – all standard civil IFR
Advanced IFR Authorization – high-density metroplex, low-vis precision, advanced RNP/AR-style or equivalent specialty operations
7) Aircraft equipment required/wanted for IFR
Minimum IFR equipment (clean-sheet baseline):
Dual independent attitude/reference capability
Certified GNSS navigator with current database
Two-way comm, with backup capability
Transponder with modern surveillance capability
Terrain and obstacle database
Moving-map display with procedure depiction
Power redundancy appropriate to aircraft class
Basic autopilot strongly preferred but required for higher-density IFR
For full-system participation:
IFR-certified WAAS/SBAS GNSS
DME/DME or equivalent backup if relevant to performance class
Data link for clearances/flow updates where available
Autopilot with approach coupling
Independent standby instruments
Digital failure annunciation clear enough to support single-pilot operations
For high-density / low-vis / advanced ops:
Dual FMS/GNSS
Coupled precision-approach capability
Enhanced surveillance and runway-incursion alerting interfaces where applicable
Robust clock/time sync for metering
Enhanced contingency capability
Not required universally:
A VOR receiver for every IFR aircraft (backup capability only required for the operations or regions that actually need it).
