Kitty Hawk / Wisk Lineage: What a Decade of eVTOL Development Teaches About Requirements

Larry Page’s backing of Kitty Hawk in 2015 was a bet that the path to flying cars ran through aggressive prototyping rather than careful systems engineering. For three years, the Flyer, Heaviside, and Cora programs ran in parallel with overlapping teams and minimal formal requirements discipline. The philosophy was deliberate: move fast, build physical hardware, learn from flight test. That approach produced genuine technical achievements. It also produced a requirements debt that the programs spent the following six years paying off—at significant cost to schedule, headcount, and in one case, the program itself.

What happened between Kitty Hawk’s founding and Wisk’s current G2 certification campaign is not a story about a company that did things wrong and then did them right. It is a story about how requirements practices that are appropriate for one phase of development become actively harmful in the next, and how recognizing that transition—and executing it—is one of the hardest organizational problems in advanced air mobility.

The Prototype Phase: Requirements as Constraints on Learning

From roughly 2015 to 2018, Kitty Hawk operated as a hardware-forward R&D shop. The Flyer, a recreational ultralight, needed to demonstrate that electric multirotor flight was achievable and marketable. Cora, the autonomous air taxi, needed to demonstrate that distributed electric propulsion and autonomous flight management could coexist on a single airframe. For both programs, the dominant engineering question was can this work at all, not how do we prove it works.

In that context, formal requirements management would have been friction without corresponding benefit. Requirements that exist to gate design decisions are valuable when the design space is understood well enough to make those decisions. Early eVTOL programs were not in that position. They were discovering the design space. Attempting to write stable system requirements before the lift architecture, propulsion margins, or autonomy stack were understood would have produced requirements that were wrong in ways that were difficult to detect—worse than having no requirements at all.

This is not a retroactive rationalization. The engineering teams at Kitty Hawk included experienced aerospace professionals who understood certification requirements. The informal approach was a choice, not an oversight. The problem is what that choice costs downstream.

The Transition Problem: When Informal Practices Hit Certification Reality

Kitty Hawk spun out Wisk as a joint venture with Boeing in 2019. Cora became Wisk’s primary program. The transition brought new governance, new funding structure, and new expectations from the FAA about what a certification campaign requires.

What it did not immediately bring was a new requirements infrastructure. The design knowledge that existed across Kitty Hawk was largely tacit—embedded in people, CAD models, test reports, and Slack channels, not in a structured requirements hierarchy. When Wisk began engaging seriously with FAA on certification basis for an autonomous air taxi, they encountered a specific problem: the FAA’s expectations for means of compliance require you to demonstrate that requirements exist, are allocated, are traced to design, and are verified. You cannot reconstruct that chain after the fact from a collection of informal artifacts. You have to build it.

Rebuilding requirements structure on top of an existing design is an order of magnitude harder than building it alongside the design. The design embeds assumptions that were never written down. When you try to write them down, you discover that some of those assumptions are contradictory, some are no longer true given design evolution, and some were never formally decided at all—they were just what someone did. Each of those discoveries is a requirement change, a design review, or a risk item. At scale, across a full autonomous aircraft program, the rework is enormous.

Wisk’s response—moving toward a more structured, model-based approach and engaging directly with FAA on an issue paper process for autonomous operations—was the right response. But the cost of arriving at that response after years of informal practice was real. Program schedules slipped. Key engineers who held critical design knowledge departed. The G2 vehicle involved significant design changes that were partly driven by the need to rationalize the requirements structure, not just by aerodynamic or safety improvements.

What Autonomous Operation Does to Requirements Complexity

Piloted aircraft certification has a partially implicit safety case. A trained pilot with type ratings is carrying a large portion of the safety margin in their head. The FAA has decades of data on what that pilot can be expected to do. Requirements for piloted aircraft can delegate a meaningful class of decisions to the pilot and call it closed.

Autonomous aircraft cannot delegate anything to a pilot. Every decision that a Wisk G2 makes in flight—from routine altitude management to emergency response to conflict avoidance—must be grounded in a requirement. That requirement must be traced to a safety objective. The safety objective must be traced to a hazard analysis. The hazard analysis must be consistent with the system architecture. The architecture must be verified by test. And the test must cover the requirement, not just the behavior the engineers happen to have tested.

This is the hard problem that distinguishes Wisk’s requirements challenge from any piloted eVTOL program. It is not just that they are certifying a new vehicle type. It is that they are certifying a new operational paradigm, and the requirements must capture the entire safety case that a pilot’s cognition would otherwise carry.

The scale of that requirement set is significant. Autonomous flight management, sense-and-avoid, system degradation modes, fail-operational architectures, and ground control station interfaces each generate hundreds of shall statements at the system level before you reach subsystem decomposition. Maintaining consistency and traceability across that set with document-based tools is functionally impossible—not because the tools are bad, but because the problem has more dimensions than documents can represent.

Requirements Stability as a Program Survival Variable

The Flyer program did not survive to certification. Kitty Hawk shut it down in 2020. The reasons were commercial, not purely technical, but requirements instability was a contributing factor. When a program does not have stable requirements, it is difficult to make confident engineering decisions. When confident engineering decisions are not being made, schedule and cost estimates are unreliable. When schedule and cost are unreliable, investor confidence erodes.

Cora/Wisk survived because it had a clearer path to a certifiable product and a committed strategic partner in Boeing. But even within the surviving program, requirements instability created localized damage. Test campaigns that were designed against one version of the requirements had to be partially repeated when requirements changed. Design decisions that were made based on informal understanding of requirements had to be revisited when that understanding was formalized. The cumulative effect on schedule was substantial.

Requirements stability does not mean requirements freeze. In a program that runs a decade, requirements will change. Customer understanding changes. Regulatory guidance evolves. Flight test reveals things that analysis did not predict. The goal is not to eliminate change—it is to manage change with enough discipline that when a requirement changes, you know immediately what downstream artifacts are affected, what verification evidence is invalidated, and what design decisions need to be revisited.

That is a traceability problem. And traceability, in a program of this complexity, is a tooling problem as much as a process problem.

How Modern Requirements Infrastructure Handles This Problem

The generation of requirements management tools that dominated aerospace in the 2000s and 2010s—IBM DOORS being the defining example—was built around document structures. Requirements exist in modules. Modules have links. The links represent traceability. This works. It has worked for certified aircraft programs for decades. But the link-maintenance burden scales with program complexity in ways that become painful for programs with the kind of cross-cutting requirements that autonomous systems generate. A single change to an autonomy interface requirement in DOORS can require manually updating dozens of traceability links across multiple modules. In practice, that maintenance does not happen consistently, which means the traceability is unreliable exactly when you need it most—during a change impact assessment.

Newer platforms have moved toward graph-based data models where the requirements are nodes in a connected structure rather than rows in a document. When a requirement changes, the graph traversal that identifies affected downstream artifacts is automated, not manual. Change impact is surfaced rather than hunted for. This is not a marginal improvement for programs like Wisk’s—it is a qualitative difference in what is operationally possible.

Tools like Flow Engineering, which was built specifically for hardware and systems engineering teams operating at this level of complexity, implement requirements as a connected engineering knowledge graph rather than a document hierarchy. The traceability is structural, not linkage-based—when you ask what is affected by a change, you get an answer from the data model rather than from a manual audit of link tables. For an autonomous eVTOL program managing thousands of requirements across multiple vehicle generations and an active FAA engagement, the difference in operational burden is significant. Flow Engineering’s deliberate focus on hardware and systems use cases means it lacks some of the process management features that large aerospace primes need for program-wide reporting, but for the core requirements-and-traceability problem, the model-native approach addresses the root issue rather than patching around it.

What Earlier-Stage Programs Should Take From This

Wisk’s decade of experience generates several lessons that are actionable for programs currently at the stage Kitty Hawk was in 2016 or 2018.

Do not wait for FAA engagement to build certification-grade infrastructure. The cost of reconstruction is always higher than the cost of building correctly the first time. If your program has any realistic path to certification, start managing requirements as if they will be reviewed by the FAA, because they will be.

Treat requirements stability as a program health metric. Track how often requirements change, where the churn is concentrated, and what is driving it. Concentrated instability in a specific area of the requirement hierarchy is a signal of unresolved design uncertainty—address the design question rather than repeatedly patching the requirements.

Autonomous operation requires explicit closure on decisions that piloted programs leave implicit. If you are building an autonomous system, your requirements must capture the full safety case. There is no pilot to absorb the residual. Start building that requirement structure early enough that it can inform design decisions rather than document them after the fact.

Organizational transitions are requirements transitions. When a program changes ownership, funding structure, or regulatory engagement, the requirements infrastructure will be stress-tested. The programs that manage these transitions best are the ones where the requirements exist in a form that new stakeholders—including investors, partners, and regulators—can engage with directly, without depending on the institutional memory of the founding team.

Honest Assessment

Wisk has made genuine progress. Their engagement with the FAA on autonomous operations, their G2 design, and their willingness to work through the hard certification questions rather than deferring them represent real maturity. The program exists and is advancing precisely because the team worked through the requirements challenges that could have ended it.

But the decade-long arc from Kitty Hawk prototypes to Wisk G2 certification campaign also demonstrates, concretely, what it costs to treat requirements as something you build for regulators rather than something you build for engineering clarity. The programs that are currently at early prototype stage—and there are dozens of them—have the opportunity to make a different choice. The tools exist. The lessons are documented in Wisk’s history. The question is whether the teams building the next generation of eVTOL aircraft will take those lessons seriously before the FAA asks them to.

The ones that do will spend less time reconstructing what their predecessors built, and more time building what comes next.