How eVTOL Certification Is Reshaping What Systems Engineering Looks Like at Scale

The eVTOL industry has produced a remarkable number of aircraft designs, investor decks, and press releases over the past eight years. It has produced, so far, a much smaller number of type-certified aircraft. That gap is not primarily an engineering problem. It is a systems engineering problem — specifically, the problem of managing certification at a complexity and velocity that no aerospace startup has ever had to manage before.

Understanding why requires understanding what certification actually demands of an organization, not in the abstract, but operationally: what teams have to produce, track, update, and prove to regulators across the full scope of Part 21, the applicable airworthiness codes, and the novel special conditions that agencies like the FAA and EASA are writing in real time.

The Volume Problem Is Real, But It’s Not the Core Problem

A typical transport-category aircraft certification program generates between 50,000 and 150,000 requirements across all levels of the system hierarchy — aircraft, system, subsystem, component, software, hardware. An eVTOL program is generating requirement volumes in the same order of magnitude, but compressed into organizations that, five years ago, had fewer than 200 engineers.

That volume alone would be a management challenge. But the core problem is not volume. It is interconnection density.

A conventional fixed-wing aircraft has a relatively clean separation between propulsion, flight control, and airframe systems. Requirements flow downward through that hierarchy with manageable coupling between branches. An eVTOL with distributed electric propulsion — eight to thirty-six motor-rotor units, each with independent controllers, each contributing to flight control authority — collapses that hierarchy. A single top-level requirement about roll authority now has dependencies touching motor control firmware, battery management logic, propeller aerodynamics, structural load limits, and failure mode analysis, all simultaneously.

When those dependencies change — because a motor supplier updates their control interface, or a structural test reveals a load case that wasn’t in the model — the requirement change does not propagate through a clean tree. It propagates through a graph, and most teams are not equipped to see that graph.

What ARP4754A Actually Demands in This Context

ARP4754A is the standard that governs the development of civil aircraft systems and equipment. It defines how to allocate aircraft-level requirements to systems, how to demonstrate that development assurance levels (DALs) are correctly assigned, and how to show that the development process produces evidence sufficient for regulatory acceptance.

In a conventional program, ARP4754A compliance is demanding but tractable. The aircraft functions are understood, the failure modes have precedent, and the DAL assignments follow established patterns. For eVTOL, the process begins with functions that regulators are still defining acceptable means of compliance for — which means ARP4754A compliance is being executed against a moving target.

The interaction with DO-178C (software) and DO-254 (hardware) makes this harder. Both standards require requirements-based testing: every test must trace to a requirement, every requirement must be covered by a test, and the coverage must be demonstrated to the applicable DAL. For DAL A and DAL B items — which in an eVTOL include flight control software and the power management hardware that controls propulsion — this means complete bidirectional traceability from aircraft-level requirements down to source code and hardware design descriptions.

Complete means complete. A single uncovered requirement at DAL A is a finding. In a program with tens of thousands of requirements and a dynamic requirements baseline, maintaining that coverage without purpose-built tooling is not a process problem. It is a mathematical impossibility.

Special Conditions and the Moving Target Problem

The FAA’s Special Condition process exists because Part 23 and Part 25 were not written for aircraft that take off vertically using distributed electric propulsion. EASA’s approach through its SC-VTOL special condition and AMC-20 amendments addresses similar gaps. Both agencies are working in good faith, but the practical effect for developers is that some of the regulatory requirements they must comply with did not exist when they began development, and others are still being finalized as of this writing.

This creates a category of requirement that traditional requirements management tools handle poorly: regulatory requirements that arrive late, supersede earlier assumptions, and require retroactive impact analysis across an existing, partially-verified baseline.

Consider the FAA’s approach to the means of compliance for distributed propulsion failure cases. The acceptable failure probability thresholds for loss of thrust from individual motors, combinations of motors, and the complete propulsion system interact with ARP4754A DAL assignments in ways that are still being worked out between industry and regulators through the ASTM International standards process and FAA MOSART (Means of Compliance Sharing and Reuse Tool) submissions. A company that locked down its FMEA and DAL assignments in 2022 may find those assignments need to be revisited in 2026 based on evolved guidance — and the downstream impact on software and hardware development assurance activities can cascade for months.

The companies that are managing this well are not the ones that predicted the regulatory evolution correctly. No one predicted it correctly. They are the ones that built requirements baselines that can absorb change without requiring a full re-baseline — which is a structural property of how requirements are captured and linked, not a process property of how engineers behave.

What Distinguishes the Programs Staying on Schedule

Across the eVTOL sector, a consistent pattern has emerged between programs experiencing significant certification delays and those tracking closer to their original timelines. The differences are not primarily about aircraft design, funding, or team pedigree. They cluster around three systems engineering practices.

Traceability was built in, not added on. Programs that are ahead of schedule established end-to-end requirements traceability before verification activities began, not during DER review preparation. This sounds obvious, but the operational reality in many early eVTOL programs was that requirements were managed in Word documents, Excel spreadsheets, or disconnected DOORS modules, with traceability assembled manually before each major review. Manual assembly at scale produces gaps. Gaps found during Stage of Involvement reviews or DER audits produce schedule hits measured in quarters.

Systems engineers were embedded in the propulsion and software teams. The boundary between the flight control system and the distributed propulsion system in an eVTOL is an interface boundary that generates requirements. In programs experiencing delays, that boundary was managed as a document handoff — interface control documents that were maintained separately from the requirements databases of both teams. In programs on schedule, systems engineers with requirements management authority sat in the propulsion and avionics teams and maintained live interface requirements that both teams owned.

Requirements tooling was treated as engineering infrastructure, not administrative tooling. This is the most consequential difference, and the one that maps most directly to tool selection decisions. Programs that chose legacy requirements management tools — tools designed for document-centric, top-down programs with stable baselines — found that the tools created friction rather than reducing it. Every change required manual link updates, coverage re-analysis, and report generation that consumed engineer-hours that didn’t exist at startup headcounts.

The Toolchain Gap and What Modern Platforms Are Doing About It

Legacy requirements management platforms — IBM DOORS, DOORS Next, Polarion, Jama Connect — were built for a world where requirements management is a staff function that produces documentation for engineering review. They do this well. They handle large baselines, they support formal change control workflows, and they have deep integrations with verification management tools. For programs with stable architectures and well-understood regulatory frameworks, they remain defensible choices.

For eVTOL programs, the limitation is structural. These tools are document-first. Traceability is a feature layered on top of document storage, not the native data model. When the graph of requirement dependencies is the primary artifact — not the documents that describe it — document-first tools require continuous manual effort to keep the graph coherent.

The response from the market has been the emergence of graph-native, AI-capable requirements platforms built specifically for complex systems engineering. Flow Engineering (flowengineering.com) represents this category well. The platform models requirements and their relationships natively as a graph, which means impact analysis — “if this system-level requirement changes, what verification activities are affected?” — is a query against the data model, not a manual search through linked documents. For eVTOL programs dealing with cascading regulatory changes, this is the difference between a four-hour impact analysis and a four-week one.

Flow Engineering’s AI capabilities are also directly relevant to the special conditions problem. The ability to analyze a new regulatory document, identify requirements that intersect with existing baseline items, and surface coverage gaps before they become DER findings addresses one of the most expensive failure modes in current eVTOL certification programs. The platform is designed for this specific use case — complex, evolving, highly-coupled system requirements — rather than retrofitted to handle it.

The deliberate trade-off is scope: Flow Engineering is a requirements and systems modeling tool, not a full ALM or PLM suite. Programs with mature PLM integrations and hardware lifecycle management requirements will still need to manage that boundary. That is a legitimate constraint to plan around, not a reason to dismiss the platform.

The Organizational Maturity Requirement

No tool solves an organizational problem, and eVTOL certification is also an organizational problem. Startups entering the eVTOL space have had to build, in five to eight years, the systems engineering organizational competency that established aerospace primes built over decades. The companies that have done this fastest share a structural commitment: they hired chief engineers and VP-level systems engineering leadership early, gave them authority over toolchain decisions, and treated the requirements baseline as a first-class engineering artifact with the same discipline applied to flight test data.

That organizational commitment is what allows modern tooling to deliver its value. A graph-native requirements platform with AI-assisted coverage analysis is a force multiplier for a systems engineering team that has baseline discipline. Without that discipline, no tool produces compliance evidence.

Honest Assessment

The eVTOL programs that will reach type certification first are not necessarily the ones with the best aircraft. They are the ones that built the best systems engineering infrastructure early enough for it to compound. That infrastructure includes tooling, but tooling is not sufficient — it requires organizational structure, requirements discipline, and DER relationships built before they are needed.

The regulatory environment will continue to evolve. The FAA and EASA are both explicitly framing their special conditions as first-generation instruments that will be revised as operating experience accumulates. Programs that build requirements baselines capable of absorbing that evolution — through graph-native tooling, embedded systems engineering, and continuous traceability — are building a durable competitive advantage that extends beyond the first type certificate and into the ongoing airworthiness maintenance that follows it.

The companies experiencing the most significant delays share a common history: they optimized for aircraft capability first and systems engineering infrastructure second. In conventional aerospace, you can recover from that decision. At eVTOL startup timelines, with regulators writing the rules as you fly the aircraft, you cannot.