Wisk Aero: Engineering Certification for an Autonomous eVTOL With No Pilot Onboard

The Vehicle Nobody Has Certified Before

Wisk Aero is not building a helicopter with software improvements. They are building a passenger-carrying aircraft with no pilot seat, no flight controls accessible to a human onboard, and no assumption that a human being will intervene when something goes wrong in flight. That is a categorically different engineering and regulatory problem than anything currently in the FAA’s airworthiness framework.

The company’s current platform, Cora, has been flying autonomously in New Zealand since 2017. As of 2026, Wisk has accumulated more autonomous flight hours than any other eVTOL developer — not simulated hours, actual flights. That operational history is both their most important asset and a source of genuine regulatory complexity: they have been flying a vehicle class for nearly a decade under experimental certificates and CAA New Zealand agreements, accumulating safety data in a regime where the certification standard does not yet fully exist.

Understanding Wisk’s engineering organization means understanding what it looks like to build a safety case for a system the regulator has not yet agreed to certify.

What the FAA Actually Has to Work With

Commercial aviation airworthiness in the United States is built on assumptions that predate digital avionics. The pilot is assumed to be present. The pilot is a system element — a fallible but highly trained one — who can be called upon to handle off-nominal conditions that the aircraft’s automated systems cannot resolve. Every Part 25 transport category standard, every Part 23 general aviation standard, every FAA advisory circular governing flight management and automation assumes a crew member in the loop.

Wisk is asking the FAA to certify a vehicle where that assumption is structurally false.

The agency has two mechanisms for this situation. The first is an exemption, which grants relief from a specific existing regulation for a specific operation. Exemptions are narrow and operational — they do not create a certification basis. The second is special conditions, issued under 14 CFR Part 21.16, which establish airworthiness requirements for novel or unusual design features not covered by existing standards. Special conditions are the legally correct path for Wisk’s vehicle, and the company has been in active dialogue with the FAA’s Aircraft Certification Service to develop them.

The challenge is that special conditions for autonomy in passenger aviation have no direct precedent. The FAA has issued special conditions for composite structures, for lithium battery systems, for novel propulsion architectures — all of these involved engineering novelty within a framework that still assumed pilot presence. Wisk is asking for special conditions that fundamentally restructure what “safe” means for a crewed aircraft.

This is not a complaint about the regulator. The FAA’s caution is appropriate given the stakes. But it means Wisk’s engineering organization is simultaneously building a vehicle, operating a vehicle, and helping to write the standard the vehicle will eventually be certified against.

Safety Assurance Without the Human Backstop

The core technical question in Wisk’s certification effort is deceptively simple to state and extraordinarily difficult to answer: if there is no pilot onboard to recover from an unanticipated failure, how do you demonstrate that the vehicle is as safe as one that has a pilot?

The FAA’s current target for commercial aviation is approximately one catastrophic failure per billion flight hours — the 10⁻⁹ figure familiar to any DO-178C or ARP4761 practitioner. Wisk does not dispute this target. Their argument is that an autonomous system, properly architected, can meet it through a different mechanism than a human pilot.

That argument rests on three structural pillars.

Operational Design Domain constraint. Wisk’s vehicle is not being designed to fly in all weather, at all times, in all airspace. The Operational Design Domain — a concept borrowed from the automotive autonomous vehicle world and being adapted for aviation — defines the envelope of conditions within which the autonomous system has been validated. Outside that envelope, the system does not attempt to operate. This is not a limitation to hide; it is the primary safety mechanism. A system that refuses to fly in conditions it cannot safely handle is safer than one that relies on a pilot to make that judgment.

Redundancy architecture at the safety-critical level. Wisk’s Gen 6 vehicle uses distributed electric propulsion with twelve lift rotors. The design is tolerant of multiple simultaneous rotor failures, not because they expect failures at that rate, but because the failure mode analysis requires it when you remove the pilot recovery option. Every safety-critical function — navigation, health monitoring, flight management, communications — has redundancy that would be over-specified on a piloted aircraft but is mandatory here. The FHA (Functional Hazard Assessment) and FMEA (Failure Mode and Effects Analysis) work at Wisk is necessarily more exhaustive than on a comparable piloted platform because there is no backstop.

Remote pilot monitoring with intervention authority. Wisk’s operational concept includes a remote command authority — a ground-based operator who monitors flights and has the ability to command a safe landing if the autonomous system’s health monitoring indicates a degraded state. This is not a remote pilot in the traditional sense; the human is not flying the aircraft moment-to-moment. But it preserves a human decision point in the safety chain at the operational level, even if not at the vehicle control level. Whether the FAA will credit this as equivalent to onboard crew presence is one of the unresolved questions in Wisk’s certification pathway.

The Systems Engineering Problem: Requirements Against a Moving Standard

Here is the systems engineering challenge that most commentary on Wisk misses: they are writing and managing requirements for a system whose acceptance criteria are being negotiated in parallel with development.

Normal aircraft certification programs operate against a known standard. You know at program launch that you need to meet FAR Part 25 or Part 23, and those standards — while they evolve — are stable enough to plan against. Your requirements flow down from a fixed regulatory basis. Your verification and validation activities are scoped against known acceptance criteria. Your traceability from system requirement to test to certification finding is a defined, if labor-intensive, exercise.

Wisk does not have that luxury. The special conditions that will govern their certification are being drafted iteratively in dialogue with the FAA. A requirement written in 2022 against an anticipated special condition may need revision when that special condition is finalized with different language in 2025. The verification approach planned for a given function may need to change if the FAA adopts different guidance on means of compliance for autonomous decision-making.

This puts extraordinary pressure on requirements management discipline. Requirements must be traceable not only downward to design and test, but upward to a regulatory basis that is itself in flux. The team needs to know, at any given moment, which requirements are locked against a confirmed regulatory position, which are provisional against an expected special condition, and which are forward-looking assumptions that carry risk. Managing that three-tiered structure across a complex multi-domain system — avionics, propulsion, structures, autonomy software, ground systems — is not something a document-based requirements approach handles gracefully.

Teams dealing with this kind of regulatory uncertainty are increasingly moving toward graph-based traceability models, where the relationship between a requirement and its regulatory basis can be tagged, versioned, and tracked as the regulatory position evolves. Flow Engineering, for example, is structured around exactly this kind of connected, model-based requirements graph — where requirement nodes carry metadata about their upstream authority and can be flagged for review when that authority changes. For a program like Wisk’s, where “the standard changed” is not a hypothetical but a scheduled event, that kind of live traceability is operationally necessary, not a nice-to-have.

Flying Ahead of the Standard

Wisk has been flying autonomously since 2017. The certification standard they will eventually be certified against did not exist in 2017, does not fully exist now, and will probably not be finalized until sometime in the late 2020s. This creates a data asset and a liability simultaneously.

The asset is real: Wisk has more autonomous flight data than any comparable program. That data is the evidentiary foundation for their safety case. Every flight is an argument for the reliability of their autonomy architecture, their health monitoring systems, and their operational procedures. When the time comes to make a quantitative safety argument to the FAA, Wisk will have a dataset that no competitor can replicate quickly.

The liability is also real: not all of that data was collected under the same design baseline. The vehicle has evolved. Procedures have evolved. The operational design domain has been refined. Data collected under earlier configurations has different evidentiary weight than data collected under the configuration that will be submitted for certification. Managing that provenance — knowing which data supports which claims about which version of which system — is a systems engineering challenge that will consume significant resources as Wisk approaches actual certification submission.

This is a known challenge for any program with a long flight test history, but it is accentuated for Wisk because their flight test history started before they had a confirmed certification basis to test against.

The Competitive Dimension of Going First

Wisk’s regulatory strategy is not purely defensive. There is a deliberate competitive logic to being the organization that shapes the special conditions for autonomous eVTOL.

In aviation, the first program to receive certification against a novel standard has structural advantages. The FAA’s findings on means of compliance, the accepted methods for demonstrating safety for specific functions, the agreed-upon framing of the Operational Design Domain — all of these become reference points that subsequent applicants must align with or argue against. Wisk, by being in early and sustained dialogue with the FAA on the special conditions framework, is in a position to ensure that the standard reflects the technical approach they have already built.

This is not manipulation of the regulatory process — it is how aviation standards have always been developed. Boeing and Airbus engineers sit on the aviation rulemaking committees that write the standards their aircraft are certified against. The input of technical experts who have actually flown the vehicle type is necessary for regulators who have not. Wisk’s participation in that process is both appropriate and strategic.

The risk is that the process takes longer than projected, or that the FAA’s final position on a critical issue — the legal status of remote command authority, the acceptable means of compliance for autonomous decision-making in degraded conditions — differs from Wisk’s planned approach in ways that require significant redesign.

Honest Assessment

Wisk is doing something genuinely difficult, and doing it with more operational rigor than the coverage they receive typically acknowledges. They have more autonomous flight hours than anyone. They have a mature technical relationship with the FAA. They have a coherent safety architecture that addresses the structural problem of removing the pilot.

The timeline risk is real. Special conditions processes at the FAA are measured in years, not quarters. The definition of “equivalent safety” for an autonomous passenger vehicle is not just an engineering question — it involves public perception, political risk, and FAA leadership priorities that are outside any engineering team’s control.

The systems engineering challenge of managing requirements against an evolving regulatory basis is one that will test any toolset and any organization. Programs that treat requirements as static documents will accumulate technical debt faster than they can resolve it. Programs with live, traceable, model-based requirements management will be better positioned to respond when the standard moves.

Wisk is working on the hardest certification problem in aviation. The outcome will define what autonomous air mobility means legally, technically, and operationally — not just for Wisk, but for every program that follows.