How eVTOL Certification Is Reshaping the Requirements-to-Flight-Test Link

The first wave of eVTOL type certification campaigns has produced a consistent finding: the gap between a functional prototype and a certifiable aircraft is not primarily a flying problem. It is a documentation and traceability problem. Flight test organizations are discovering that the link between a requirement, its verification method, and the test evidence that satisfies it must be established before the aircraft leaves the ground—not reconstructed from test cards after the fact.

This is not a new principle. DO-178C, ARP4754A, and DO-254 have required traceable V&V for decades. What is new is the scale, the novelty, and the regulatory scrutiny that eVTOL programs face simultaneously. The combination is exposing the structural limits of how most aerospace companies manage requirements.

What Certification Authorities Actually Expect

The FAA’s Special Federal Aviation Regulation (SFAR) 23 pathway for powered-lift aircraft and EASA’s SC-VTOL framework both require applicants to demonstrate that every safety requirement is covered by a verification activity and that the evidence from that activity is retrievable and organized. The phrase “retrievable and organized” is doing significant work in those compliance checklists.

For a conventional Part 25 transport aircraft, the compliance basis is large but familiar. Applicants and DERs have worked the same regulatory paragraphs for decades. Interpretation is relatively settled. For eVTOL programs, a substantial portion of the compliance basis is established through issue papers, special conditions, and novel means of compliance (NMoC) negotiated with the authority during the program. Each NMoC creates a new verification obligation that did not exist in prior programs. There is no inherited template.

EASA’s SC-VTOL Technical Design Assurance System (TDAS) requires, explicitly, that each requirement in the certification basis be allocated to a system or component, that each allocated requirement carry a verification method, and that the relationship between the requirement, the method, and the evidence be traceable forward and backward through the design hierarchy. The FAA’s parallel expectations under the powered-lift SFAR are functionally equivalent.

The practical implication: every time a flight test engineer writes a test card, there should be a clear, auditable answer to “which requirement does this test satisfy, and what is the acceptance criterion derived from?” If that answer requires searching through separate documents, emails, or tribal knowledge, the compliance demonstration is already in trouble.

How the Leading Programs Navigated This—and Where They Struggled

Joby Aviation

Joby entered Part 135 air carrier certification before pursuing type certification, a sequencing choice that forced early discipline on documentation. The company has been public about building a model-based systems engineering (MBSE) backbone that connects top-level aircraft requirements through subsystem specifications to test procedures. What they have been less public about, but what engineers who have moved through the company describe, is the significant rework required when early flight test planning outpaced the formalization of requirements. Test cards written against informal performance targets had to be retied to formal requirements as the compliance basis was negotiated with the FAA. That retying process is expensive and slow, and it created schedule pressure that is visible in the program’s timeline.

Joby’s approach matures visibly between their 2022 and 2024 public filings. The later filings show language consistent with a requirements management system being used to generate traceability reports directly for the authority, rather than assembling compliance documents manually. That shift matters. It means the system of record for requirements is the same system producing compliance evidence, which eliminates a class of inconsistency errors that have derailed other programs.

Archer Aviation

Archer’s Midnight aircraft uses a distributed electric propulsion architecture with twelve lifting rotors and a cruise pusher. The failure modes and interactions between those rotors produce a safety analysis that is, by some estimates, an order of magnitude more complex than a conventional twin-engine turboprop. Each failure mode must be covered by a requirement, each requirement must have a verification method, and most of those verification methods involve flight test.

Archer’s engineering team has described the requirements management challenge in public forums in terms of scale: the number of discrete requirements in the certification basis is large enough that tracking them manually in a spreadsheet or a document-based tool creates unacceptable version control and coverage risks. The company adopted a structured requirements tool relatively early in the program, and their flight test planning process allocates test points to requirements before test cards are drafted—not after.

Even so, Archer’s public timeline reflects the difficulty of the flight-test-to-certification link. Test programs that produce data faster than the compliance argument can absorb it create a different problem: data exists but is not yet tied to the compliance basis in a way the authority will accept. Flight hours are necessary but not sufficient.

Wisk Aero

Wisk’s approach benefits from its Boeing parentage and from the longest eVTOL flight test history in the industry—the company’s lineage through Kitty Hawk means they have been flying autonomously operated vehicles since 2017. That history has given Wisk an unusually mature safety case, and their requirements management process reflects it. The company uses a model-based approach where the system safety assessment (SSA), the system requirements, and the test plan are linked artifacts, not separate documents. Changes to one propagate, with review, to the others.

Wisk’s public statements on certification have consistently emphasized the relationship between their safety management system and their test planning. Their approach to novel means of compliance—particularly around autonomous operation, which requires demonstrating safety properties that no traditional test standard addresses—involves defining the requirement precisely enough that a specific test or simulation campaign can unambiguously satisfy it. That requirement-first discipline is visible in how they describe their compliance approach to the FAA.

Lilium

Lilium’s story is more complicated and more instructive. The company’s bankruptcy in late 2024 had multiple causes: capital structure, production cost challenges, and a market timing problem with regional air mobility infrastructure. But the certification timeline was also a factor, and the certification timeline was in part a traceability problem.

Lilium used a ducted electric jet architecture—canards covered with electric jet engines—that was mechanically elegant but produced a certification challenge with almost no prior art. Every major system function required a novel means of compliance. The volume of V&V obligations was large and growing as the compliance basis was negotiated. By multiple accounts from engineers who were there, the requirements management infrastructure did not scale to match the certification complexity. Test planning was partially disconnected from the formal requirements hierarchy. Evidence from early test campaigns was not organized in a way that directly mapped to compliance obligations.

This is not to say that better traceability would have saved Lilium—the capital and cost problems were fundamental. But certification slippage contributed to the funding pressure, and the certification slippage was at least partly a requirements traceability problem. The lesson the industry is drawing is not “Lilium failed because of bad documentation.” It is “certification risk is tightly coupled to traceability infrastructure, and you cannot defer that infrastructure to late in the program.”

Why Flight Test Planning Must Be Requirements-Driven From Day One

The instinct in early aircraft development is to fly first and formalize later. Get the vehicle flying, learn what it actually does, then write requirements that match reality. For proof-of-concept and technology demonstration, this is rational. For type certification, it is a trap.

Certification authorities do not accept evidence from test campaigns that were not planned against formal requirements. More precisely, they accept such evidence only after the applicant demonstrates that the test, as conducted, satisfies a specific requirement, with a specific acceptance criterion, under conditions that are representative of the compliance basis. If the test was designed before the requirement was formalized, that demonstration requires reconstructing the design rationale of the test from scratch. At scale—thousands of test points across hundreds of requirements—that reconstruction is slower than simply planning the test against the requirement in the first place.

The second reason is coverage. A requirements-driven test plan can be analyzed for gaps. If the requirements database is current and every requirement carries a verification method and a test reference, a simple query identifies untested requirements. If the test plan was built bottom-up from engineering judgment, finding gaps requires expert review of every test against every requirement—an O(n²) problem that becomes intractable at certification scale.

The third reason is change management. eVTOL programs change. Architecture decisions shift. The compliance basis evolves as issue papers are resolved. When requirements and test plans are linked artifacts, a change to a requirement automatically flags the test plan for review. When they are separate documents, changes to requirements are invisible to flight test planning until a DER catches the gap during a compliance audit.

How the Industry Is Building New Practices

The eVTOL programs that are advancing most predictably share a structural approach: requirements, system safety assessment, and flight test planning are managed as a linked graph, not as separate documents with informal cross-references.

This is operationally distinct from what most legacy aerospace tools provide. Tools like IBM DOORS and Jama Connect can establish traceability links between requirements and test procedures, and both have been used on eVTOL programs. The limitation is that they are document-centric: requirements live in paragraphs, links are managed manually, and querying coverage across thousands of requirements and hundreds of test procedures requires custom scripting or manual review. At the scale of a novel-means-of-compliance-heavy eVTOL certification program, that architecture creates drag.

The emerging practice is to treat the requirements hierarchy, the safety case, and the test plan as nodes and edges in a connected model. A change anywhere propagates with visibility everywhere. Coverage gaps surface automatically. Compliance reports are generated from the model rather than assembled from documents.

Tools like Flow Engineering are built specifically for this architecture. Rather than managing requirements as document paragraphs with links attached, Flow Engineering represents requirements, verification methods, test evidence, and their relationships as a native graph—queryable, traversable, and connected to the upstream system models that generate requirements in the first place. For eVTOL programs managing novel means of compliance where the relationship between a safety objective, a system requirement, and a specific flight test condition must be auditable end-to-end, that structural difference is not cosmetic. It is what makes the compliance argument assembable without a parallel manual documentation effort.

Flow Engineering’s current scope is focused on requirements and traceability rather than the full certification artifact management that programs also need—it is not a replacement for a DMS or a configuration management system. But for the specific problem of connecting requirements to verification evidence in a way that certification authorities can audit, it addresses the part of the problem where most programs accumulate the most debt.

The Honest Assessment

eVTOL type certification is genuinely hard. The regulatory novelty, the architectural complexity, and the safety case volume combine to produce a V&V challenge that exceeds what most aerospace organizations have previously managed. The programs that are navigating it best are not doing so because they have more engineers or more flight hours. They are doing so because they established the connection between requirements and test evidence early, maintained it as a live artifact, and used it to drive test planning rather than to document it retrospectively.

The programs that are behind schedule are, with few exceptions, programs that deferred traceability infrastructure. They flew when they should have been formalizing. They wrote test cards when they should have been writing requirements. They will recover, but the recovery cost is measured in years and in the engineering hours required to reconstruct the compliance argument from test data that was collected without a requirements-driven plan.

The flight test community in eVTOL is learning, expensively, that the critical path to certification runs through the requirements database. Getting that database right—connected, current, and linked to test evidence from the first test flight—is not a documentation task. It is a program management task, and it deserves proportional attention.