Why eVTOL Programs Are the Most Systems-Engineering-Intensive Programs in Aviation History

Certified aircraft programs have always been hard. The 787 consumed an estimated 50 million engineering hours before first delivery. The F-35 remains the most expensive defense program in history. But both of those programs, despite their complexity, had something eVTOL developers do not: a certification template that existed before the airplane did.

eVTOL programs are operating without that anchor. The airworthiness standards, the means of compliance, the failure classification boundaries, and in some cases the fundamental physics assumptions — all of it is being written simultaneously with the engineering. That is not an exaggeration or a marketing complaint from programs trying to explain schedule slips. It is the structural reality that defines eVTOL systems engineering in 2026.

The Baseline Problem: Certification Basis as a Moving Requirement

Every civil aircraft program begins with a certification basis — the regulatory standard the aircraft must meet to receive a type certificate. For conventional fixed-wing transport aircraft, that is Part 25. For small general aviation, Part 23 (as revised by ASTM standards). Rotorcraft use Part 27 or 29. These frameworks are mature. They have decades of means of compliance, advisory circulars, and precedent decisions behind them.

eVTOL aircraft do not fit cleanly into any of these. The FAA created the powered-lift category in regulation (14 CFR Part 1 defines it), but the airworthiness standards for powered-lift at the complexity level of urban air mobility vehicles did not exist in usable form when most current programs began certification. The FAA’s primary mechanism for addressing this gap has been Special Conditions — rulemaking instruments that establish novel or additional requirements for specific aircraft when existing regulations are inadequate.

Special Conditions are not plug-and-play additions. Each one is negotiated between the applicant and the FAA on a program-by-program basis. What Joby agrees to for its acoustic emission requirements does not automatically apply to Archer or Lilium’s successor programs. What Wisk accepts for its autonomous flight control Special Condition does not transfer to a piloted eVTOL from Beta Technologies. Every program is, in effect, constructing part of its own regulatory framework as an engineering deliverable.

This creates a requirements management situation with no parallel in conventional aviation. Requirements are not stable inputs to engineering — they are outputs of an ongoing negotiation with the certifying authority, and they change. When a Special Condition is revised, every downstream requirement, every design decision it touched, every test plan built on it, needs to be re-evaluated. In a document-based requirements environment, that re-evaluation is manual, slow, and error-prone. In a program operating under schedule pressure measured in investor runway, it is a program risk.

AC 21.17-4 and What It Actually Requires

The FAA’s Advisory Circular 21.17-4, which addresses type certification of powered-lift aircraft, has become a central document for eVTOL programs seeking to understand what a structured path to certification looks like. It is not a simple checklist. It is a framework for how programs should approach the construction of their own certification basis under the powered-lift category.

Several aspects of AC 21.17-4 have direct systems engineering implications that are worth understanding concretely.

Development Assurance. The AC explicitly references the need for development assurance processes consistent with the complexity and novelty of the system. For software-intensive flight controls — and every credible eVTOL has software-intensive flight controls — this means DO-178C compliance at levels commensurate with the failure condition classification of the functions the software performs. For a fly-by-wire flight control system on a vehicle with no mechanical backup, the relevant software functions are almost certainly DAL-A. DAL-A software development is not a process you layer onto an existing agile engineering workflow. It restructures the workflow.

Failure Condition Classification Under Novel Physics. Part 25 and Part 27 have established conventions for what constitutes catastrophic, hazardous, major, and minor failure conditions. eVTOL vehicles with distributed electric propulsion (DEP) challenge those conventions directly. A single motor failure on a DEP vehicle may be a minor event if the control laws are designed for it. Loss of a motor controller bus may be catastrophic depending on architecture. The failure-condition classification process has to be re-derived from the vehicle’s actual aeromechanics and control authority margins, not borrowed from rotorcraft convention. That derivation is a systems engineering activity, and it feeds directly into the hardware and software assurance requirements for every component in the propulsion chain.

Means of Compliance Negotiation. AC 21.17-4 explicitly acknowledges that applicants will need to propose novel means of compliance for conditions where existing MOC guidance does not apply. Proposing a MOC is not a documentation task. It requires understanding what the regulation is trying to protect against, demonstrating that the proposed method provides equivalent protection, and building the test and analysis program to substantiate that claim. This is advanced systems engineering work, and it has to be traceable back to requirements that may themselves still be under negotiation with the FAA.

The Interaction Density Problem

There is a systems engineering metric that rarely appears in program dashboards but that experienced SE leads understand intuitively: requirement interaction density. For any given requirement in a complex system, how many other requirements does it interact with? How many design decisions does it constrain? How many verification events does it generate?

eVTOL programs have the highest requirement interaction density of any aircraft category because every major engineering domain is simultaneously novel.

Consider what is simultaneously new on a representative eVTOL:

• Propulsion: Distributed electric motors with no certified heritage at this operating point. Battery systems with thermal runaway failure modes that have no analog in fuel-fed propulsion. Power electronics operating at switching frequencies and current densities that create EMI environments that didn’t exist on previous platforms.

• Flight controls: Fully software-defined flight control with no mechanical reversion. Control laws that manage 6-18 independent thrust-generating devices simultaneously. Failure mode coverage that has to account for asymmetric motor failures, partial battery pack losses, and degraded GPS environments simultaneously.

• Structures: Certification of composite structures under novel load cases — including the dynamic loads from multiple rotors at varying speeds, hover-to-cruise transition loads, and ground resonance boundaries that differ from helicopter certification practice.

• Human factors and the operating environment: Urban operating environments with obstacle density, turbulence characteristics, and communication infrastructure that Part 29 guidance was not written to address. Pilot workload profiles for vehicles that can auto-transition between flight regimes and may fly partially or fully autonomous in future variants.

None of these are independent. The battery thermal management requirements interact with the structural requirements because thermal protection mass affects weight and balance. The EMI environment from the power electronics interacts with the flight control software’s sensor inputs. The failure mode coverage requirements for software interact with the hardware assurance requirements for motor controllers. The human factors requirements for urban operations interact with the automation authority requirements from the Special Conditions.

In a document-based requirements tool, these interactions are comments in Word documents, cells in a shared spreadsheet, or informal knowledge held by senior engineers. When a design decision changes, that knowledge is not reliably propagated. In eVTOL programs, where design decisions change frequently under the combined pressure of physics, certification feedback, and investor timelines, that propagation failure becomes a certification risk.

How Leading Programs Are Structuring to Survive

The programs that are making credible certification progress in 2026 have organized their engineering functions around a common insight: traceability is not a documentation requirement at the end of the program. It is the mechanism by which they survive the ongoing churn in their certification basis.

Vertical integration of certification and design engineering. At Joby, Archer, and Wisk, the systems engineering function is not a downstream validation step. SE leads are embedded in the negotiation of Special Conditions and in the translation of FAA feedback into engineering requirements. The certification basis is not handed to engineering — it is developed by engineering in collaboration with the DER and FAA aircraft certification office. This structural choice accelerates the feedback loop between regulatory input and design response.

Model-based systems engineering as a survival mechanism. The programs with the most coherent requirements architectures are using model-based SE environments that maintain live traceability between regulatory requirements, derived requirements, design decisions, and verification events. The objective is not to satisfy a process requirement for MBSE. The objective is to be able to answer, within hours, the question: “If the FAA revises this Special Condition, what breaks?” In a document environment, that question takes weeks and produces an incomplete answer. In a graph-based model, it is a query.

Requirements management as a first-class engineering discipline. The programs struggling with schedule are, in most cases, programs that treated requirements management as a documentation function staffed by junior engineers using DOORS or a spreadsheet. The programs making progress have staffed requirements management with senior systems engineers who have the domain knowledge to understand the implications of a requirement change across propulsion, avionics, structures, and operations simultaneously.

Tools that support this model need to provide graph-based traceability, live requirement change impact analysis, and integration with both the regulatory documentation workflow and the design artifact repositories where requirements actually connect to implementation. Flow Engineering’s architecture — built around graph-based requirement models rather than document hierarchies — is designed for exactly this kind of high-interaction-density environment. Its ability to surface downstream impact when an upstream requirement changes is operationally significant in a program where the upstream requirements are themselves a negotiated, evolving deliverable. It is not the right tool for programs that need full DO-178C artifact generation or deep PLM integration out of the box, but for programs trying to maintain coherent systems-level traceability through certification basis evolution, it addresses the actual problem.

The Cost of Getting This Wrong

The consequences of inadequate systems engineering rigor in eVTOL programs are not theoretical. Several programs that entered development between 2018 and 2022 have encountered certification stalls that trace back to requirements architecture failures: test programs that could not be connected back to the specific regulatory requirements they were meant to satisfy; failure mode analyses that were not reconciled with the software assurance requirements derived from the same failure conditions; Special Condition commitments made in early FAA meetings that were not propagated into downstream engineering requirements.

These failures are expensive not only because they delay certification but because they require retroactive reconstruction of the traceability record — a process that often costs more engineering time than building the traceability correctly would have, and that is inherently less reliable because the design decisions that need to be explained were made by engineers who may no longer be at the program.

Honest Assessment

eVTOL programs are not failing because the physics are impossible or because the technology isn’t ready. The vehicles fly. The energy storage is marginal but workable for initial operating envelopes. The obstacle is certification, and certification is failing where systems engineering is inadequate.

The FAA is not being obstructionist. The agency is being appropriately rigorous about a novel vehicle category that will operate over populated areas without the fault-tolerance margins that commercial transport aircraft carry. The programs that understand this — that treat certification rigor as a technical requirement rather than a regulatory burden — are the ones making progress.

The systems engineering challenge in eVTOL is not about the volume of requirements. It is about the interaction density, the regulatory dynamism, and the simultaneous novelty across every engineering domain. Meeting that challenge requires organizational structure, tooling, and staffing decisions that many programs made incorrectly in their early years and are now paying to correct.

The programs that survive to type certificate will be the ones that built their requirements architecture to handle change, not the ones that built it to look complete at a program review.