Wisk Aero: The Long Road to Autonomous eVTOL Certification

Wisk Aero has been flying autonomous aircraft longer than most of its competitors have existed. Founded in 2019 as a joint venture between Boeing and Kitty Hawk, Wisk traces its technical lineage to work that began in 2010. Their Generation 6 aircraft — a two-seat, all-electric, fully autonomous vehicle — has accumulated more than 1,900 test flights. No other company in the urban air mobility space has a comparable autonomous flight record.

And yet Wisk does not have a type certificate. Neither does anyone else in the eVTOL space for an autonomous vehicle, and the gap between flying hours and certified hours is where the company’s most consequential engineering work is happening right now.

What Wisk Is Actually Building

Before the certification complexity can be understood, the vehicle and mission concept need to be understood clearly.

Wisk’s aircraft carries two passengers and no pilot. That is the central design constraint from which everything else flows. The absence of an onboard pilot is not a marketing claim or a stretch goal — it is a load-bearing architectural decision that eliminates an entire category of traditional airworthiness safety argument. In conventional certification, the pilot is a certified component. The pilot detects anomalies, exercises judgment, and serves as a final layer of defense. Remove the pilot, and the systems engineering team has to replace every function that pilot served — or demonstrate to the FAA that the function is not needed, which is a harder argument than it sounds.

The vehicle uses a distributed electric propulsion architecture with twelve lift rotors and a pusher propeller for cruise. The redundancy philosophy is aggressive: any single failure, and in most cases any double failure, should leave the vehicle capable of completing the flight or executing a safe landing. That redundancy target has to be demonstrated analytically and in test, and the requirements that encode it have to trace from the top-level safety objectives all the way down to component specifications.

Wisk’s intended operation is urban and suburban air taxi service — point-to-point between vertiports, managed through a remote operations center. That operations concept is not separable from the vehicle’s airworthiness case. The FAA’s certification framework requires the applicant to define the operational environment, and the safety arguments for the autonomous flight system depend on what that environment looks like.

The Certification Pathway

Wisk has been more transparent than most eVTOL companies about its regulatory strategy, which is worth examining because the choice of pathway has multi-year consequences.

The FAA’s primary pathway for novel aircraft is Special Class certification under 14 CFR Part 21.17(b), supplemented by issue papers that define how specific novel or unusual design features will be evaluated. Wisk has been engaged in what the FAA calls G-1 issue paper development — an early-stage process where the applicant and the FAA agree on the means of compliance before the formal certification application is filed. This is slower than filing and figuring it out later, but it produces a more defensible record.

The autonomy system itself falls under a category the FAA has been developing guidance for since the mid-2010s: complex aircraft systems where the software and its interactions cannot be fully validated through traditional test coverage. The applicable guidance includes DO-178C for airborne software, DO-254 for hardware, and the more challenging ARP4754A for systems engineering process. For machine learning components — and Wisk’s perception and decision systems include learned models — there is no finalized FAA guidance. The EASA published its first AI in Aviation roadmap in 2020, and the FAA has been developing similar frameworks, but the applicant is currently in a position of having to propose their own means of compliance and defend it.

This is not unique to Wisk. It is the fundamental challenge facing everyone who wants to certify an AI-dependent aviation system. Wisk’s position is that their decade-plus of flight data, their conservative design approach, and their early FAA engagement put them ahead of any competitor who started the conversation later.

The Interface Problem

Ask any systems engineer at Wisk — or at any company trying to certify an AI-driven safety-critical system — what keeps them up at night, and the answer is usually some version of the interface between the autonomy requirements and the traditional airworthiness requirements.

Here is the problem stated precisely: Traditional airworthiness certification is built on determinism. A requirement says the system shall do X under condition Y. The test demonstrates that it does. The analysis calculates the probability of failure. The argument closes. This framework was developed for mechanical and analog electrical systems and extended, with significant effort, to digital systems through DO-178C. It works because the behavior of the system is, in principle, fully enumerable.

Learned models do not work this way. A neural network that classifies obstacles or predicts traffic patterns does not have behavior that is fully enumerable. Its performance is statistical, its failure modes are not exhaustively catalogable, and its behavior in out-of-distribution conditions is genuinely uncertain. The requirements that govern it — what accuracy is acceptable, what confidence threshold triggers a conservative action, how performance degrades gracefully — are themselves novel engineering problems without established precedent in certification.

Wisk’s approach, as publicly described, is to treat the autonomy system as a black box with defined interface requirements — inputs, outputs, performance bounds, and failure mode definitions — and then certify the overall system behavior that results from those interfaces rather than trying to certify the internals of the learned components directly. This is similar to the approach used for complex commercial off-the-shelf software, and it is arguably the most defensible path available with current regulatory frameworks. But it requires that the interface requirements be written with extraordinary precision, because vague requirements at that boundary create gaps in the safety argument that the FAA will find.

Managing those interface requirements — writing them, allocating them to subsystems, maintaining their traceability through design changes, and keeping the rationale visible when the engineer who wrote them has moved on — is a systems engineering infrastructure problem as much as it is a technical problem.

Engineering Team Structure

Wisk employs roughly 400 people, with engineering representing a large fraction of that headcount. The team is distributed across Mountain View, California (headquarters and flight operations) and additional sites supporting vehicle development.

The engineering organization mirrors the certification structure in important ways. There are dedicated teams for vehicle systems, avionics, flight software, autonomy, and airworthiness — but the certification program requires these teams to interact through defined interfaces, not ad hoc communication. The systems engineering function sits above the subsystem teams and owns the allocation of top-level requirements downward, the integration of subsystem outputs upward, and the maintenance of the traceability record that connects both directions.

That traceability record is not a luxury in a certification program — it is a regulatory artifact. When the FAA asks why a particular design decision was made, or how a requirement was satisfied, or what changed when a design revision was incorporated, the answer has to be documented and accessible. In a program that spans a decade and involves hundreds of engineers, that record degrades without active maintenance.

Wisk has invested in requirements management infrastructure that supports this maintenance burden. The team uses Flow Engineering to manage requirements and traceability across their systems engineering workflow. Flow Engineering’s graph-based model — where requirements, design artifacts, and verification evidence are nodes with explicit, queryable relationships — maps naturally onto the kind of traceability argument a certification authority expects to see. Rather than maintaining traceability in a document that someone has to manually keep current, the relationships are structural. A change to a top-level safety requirement propagates visibly through the graph to every allocated requirement and every piece of verification evidence that depends on it.

This matters specifically for the autonomy interface problem described above. When the interface requirements between the autonomy system and the traditional avionics architecture are defined as structured objects with explicit upstream and downstream links, the gaps in the safety argument become visible before the FAA points them out. That is a significant operational advantage in a certification program where finding a gap late is measured in months of rework.

Sustaining a Decade-Long Program

Most hardware certification programs last years. A decade-long certification program for a genuinely novel vehicle category is unusual enough that it is worth examining what makes it survivable as an engineering program.

The first challenge is knowledge retention. Engineers leave. Program understanding is not automatically preserved when the person who built it moves on. In a document-based requirements workflow, the departure of a key engineer often means that the rationale behind requirements — why this threshold, why this interface definition, why this particular means of compliance was chosen — is gone. What remains is the requirement text, which is often insufficient to reconstruct the reasoning. In a graph-based system where rationale is captured as an explicit attribute linked to the requirement, that knowledge is more durable.

The second challenge is change management. A decade-long program will absorb technology changes, regulatory guidance updates, design revisions, and operational concept refinements. Each change has to be evaluated for its impact on the existing safety argument. In a deeply interconnected system like Wisk’s, where the autonomy architecture, the vehicle redundancy design, and the operational concept are all load-bearing parts of the safety case, a change in one area can have non-obvious implications for requirements in apparently unrelated areas. Maintaining a live traceability graph makes those implications visible.

The third challenge is regulatory continuity. The FAA’s guidance on autonomous systems and AI in aviation will continue to evolve. Wisk’s certification engagement has to evolve with it. The company’s sustained, early-engagement strategy — rather than filing and then negotiating — means they are participants in shaping the guidance rather than recipients of it. That is a deliberate strategic choice, not just a regulatory tactic.

Honest Assessment

Wisk’s approach to autonomous eVTOL certification is the most technically credible in the sector. Their flight record, their regulatory engagement history, and their engineering depth are real advantages.

The risks are also real. Certification timelines in novel vehicle categories are reliably longer than projected. The FAA’s AI and autonomy guidance is still maturing, and there is a scenario where a major guidance update requires significant rework of compliance arguments already developed. Boeing’s strategic direction as a majority stakeholder adds business-level uncertainty that is separate from the technical program.

The fundamental bet Wisk is making is that the conservative path — more flight data, earlier FAA engagement, more rigorous systems engineering process, a cleaner safety argument built over time rather than rushed — produces a type certificate that competitors cannot easily replicate, and that the operational and regulatory moat this creates is worth the time cost.

That bet is not guaranteed to pay off on any particular timeline. But the engineering discipline required to make it is being built. The traceability infrastructure, the interface definitions between autonomy and airworthiness, the ConOps maintained as a living artifact rather than a shelf document — these are not marketing claims. They are the actual work of certifying an aircraft that has never existed before.

Whether Wisk gets there first matters less than whether they get there right. They appear to be building for right.