Joby Aviation and the New Model for Certification-Driven Hardware Development

The standard arc of aerospace certification looks something like this: design the aircraft, freeze the configuration, write the requirements, build the compliance documentation, present it to the regulator, negotiate for years. The process is sequential, document-heavy, and deliberately conservative. It was built for an industry where design changes are expensive and programs move slowly.

Joby Aviation is running a different playbook. And by March 2026, when the company completed Stage 4 of the FAA’s type certification process for its S4 electric air taxi, the results of that approach had become impossible to ignore.

What Joby Is Actually Building

The S4 is a six-tilt-rotor electric aircraft designed to carry a pilot and four passengers at up to 200 mph over a range of roughly 100 miles. On the ground, the rotors tilt vertical for lift. In cruise, they tilt forward like conventional propellers. It is simultaneously a helicopter, a fixed-wing aircraft, and something that doesn’t map cleanly onto either category — which is precisely the regulatory challenge.

Joby must satisfy FAA Part 23, the airworthiness standard for small aircraft, while also complying with the FAA’s newer Special Conditions and Issue Papers specifically developed for powered-lift vehicles. These standards were written, in part, because aircraft like the S4 didn’t exist when Part 23 was codified. The company is not just certifying a product. It is, in some cases, helping define the standards the product will be measured against.

The S4 flew over 9,000 miles in flight testing during 2025. The program has accumulated hundreds of thousands of individual certification test points spanning structural, propulsion, avionics, software, and airworthiness domains. With Stage 4 complete, type certificate issuance is expected before the end of 2026, with first passenger flights targeted within the same window.

No other eVTOL program is this close.

The Structural Problem Legacy Aerospace Doesn’t Solve Well

To understand what makes Joby’s engineering challenge distinctive, consider what happens when a design changes late in a traditional certification program. An engineer modifies a composite panel geometry to address a flutter finding from a flight test. That change propagates: the weight budget shifts, the load path changes, the FEA models need updating, the test matrix expands. In a document-centric program, tracking all of those dependencies manually — across requirements documents, test plans, compliance matrices, and interface control documents — is an enormous coordination problem. It creates lag. It creates gaps. It creates the kind of quiet inconsistency that surfaces as a finding during a certification audit.

For an aircraft with the S4’s architecture, this problem is amplified. The tilt-rotor transition regime creates coupled dynamics between the propulsion system, flight control software, and structural loads that don’t decompose cleanly. A change to rotor rpm scheduling during transition affects vibration loads, which affects fatigue life assumptions, which affects maintenance intervals, which affects the operational specifications the FAA approves. The dependency graph is deep and cross-domain.

Legacy requirements tools — IBM DOORS, Polarion, even newer SaaS platforms grafted onto document workflows — were designed to manage requirements as a hierarchical text structure. They handle decomposition well. They handle change propagation across a live multi-domain model poorly.

Iterative Flight Test as Certification Evidence

The strategic insight at the center of Joby’s approach is treating every flight test cycle as a compliance event, not just a learning event. In traditional development, flight testing and certification documentation are loosely coupled: you fly, you learn, you update the design, and eventually you consolidate the evidence. The compliance matrix is something you build toward the end.

Joby’s model closes that loop faster. Test objectives are mapped to specific compliance findings before the flight. Data from each sortie feeds directly into the certification evidence base. Design updates that result from test findings are tracked against the affected requirements immediately, not retrospectively. The compliance picture stays current with the design.

This requires something traditional certification programs rarely have: a requirements and traceability layer that moves at the speed of engineering, not the speed of documentation. When an engineer changes a structural interface definition on a Tuesday, the downstream effects on test coverage and compliance mapping need to be visible before Thursday’s test planning meeting — not in the next document release cycle.

How Modern Tooling Enables This

This is where the organizational infrastructure behind Joby’s program becomes relevant. The company uses Flow Engineering to manage its MBSE environment, requirements structure, and cross-team design alignment during what is, by any measure, an extremely high-velocity certification push.

Flow Engineering is built around a graph-based model of system relationships rather than a document hierarchy. Requirements, design elements, test cases, and compliance evidence all exist as nodes in a connected model. When an engineer updates a design parameter, the tool surfaces which requirements are affected, which test cases need re-evaluation, and which compliance findings may be invalidated. This is not a manual traceability matrix — it is a live dependency model that updates as the design evolves.

For a program with hundreds of thousands of test points across domains as different as battery thermal management, fly-by-wire software, and acoustic certification, that kind of connected traceability is not a convenience. It is a prerequisite for running the kind of iterative, evidence-dense certification program Joby is running.

Flow Engineering’s design also reflects a deliberate choice about where AI should be applied in hardware development. Rather than adding AI features to a legacy document workflow, the tool is built from the ground up to support model-based reasoning — surfacing inconsistencies, flagging traceability gaps, and helping teams understand the impact of changes before they propagate into expensive rework. For a company operating at the edge of what the FAA has certified before, reducing the lag between design state and compliance state is a direct competitive advantage.

It is worth being precise about what this tooling does and does not do. Flow Engineering is not a substitute for engineering judgment, and it does not automate the FAA relationship. Certification still requires human experts, formal test witnesses, and a regulator that makes its own calls. What the tooling does is remove coordination friction — the organizational drag that accumulates when teams are working from inconsistent views of a rapidly evolving design.

What Legacy Aerospace Gets Right — and Why It’s Not Enough Here

It would be a mistake to frame this as legacy aerospace being wrong. The DO-178C software standard, the AC 23-series airworthiness criteria, the structured test witnessing protocols — these exist because aircraft failure modes are catastrophic and irreversible. The FAA’s conservatism is earned.

What legacy process is not optimized for is a configuration space that changes frequently, a multi-domain system where software and hardware are deeply coupled, and a regulatory environment where the standards themselves are still being written. Established primes running A320 derivative programs can afford to freeze a configuration early and manage certification as a documentation exercise. Joby cannot, and the S4’s novel architecture would not permit it even if the company wanted to take that approach.

The Joby program is not rejecting rigor. It is applying rigor at a faster update cadence, with tooling capable of maintaining consistency across that cadence. Those are different things.

What This Signals for the Industry

Joby’s position — furthest along in type certification, running an iterative evidence-based test program, and targeting passenger service within the year — is a data point about more than one company. It illustrates something broader about how the next generation of complex hardware development will work.

The convergence of tight software-hardware integration, novel regulatory territory, and fast design iteration cycles is not unique to eVTOL. It shows up in autonomous ground vehicles, next-generation satellites, advanced defense platforms, and anywhere else that a systems architecture is being defined while the product is also being tested. In all of these domains, the gap between design state and compliance state is a liability, and the tools that close that gap faster create real engineering leverage.

The S4 program has also surfaced something that should interest any systems engineer working in a novel certification domain: the relationship between requirements management fidelity and regulatory credibility. The FAA’s confidence in a certification submission is partly a function of how well the applicant can demonstrate that they understand the system they built — that every design decision is traceable to a requirement, every requirement is traceable to a standard, and every change has been properly assessed for downstream effects. That kind of demonstrable rigor requires infrastructure. It does not emerge from spreadsheets and shared drives.

An Honest Assessment

Joby is not guaranteed a type certificate, and first passenger flights in 2026 remain a target, not a fact. Certification programs at this level of novelty carry inherent schedule risk, and the FAA makes its own timeline. The S4 completing Stage 4 is a meaningful milestone — it demonstrates that the aircraft’s design basis is accepted and that the compliance framework is credible — but it is not the finish line.

What is already demonstrable is that Joby has run the most technically sophisticated eVTOL certification program in history, faster than any peer, on an aircraft that required negotiating new regulatory frameworks in parallel with developing the vehicle. The organizational and tooling decisions behind that execution are part of the story.

For engineers watching from adjacent industries, the relevant question is not whether eVTOL specifically succeeds. It is whether the development model Joby represents — iterative, model-based, evidence-continuous — is better suited to complex novel hardware than the document-centric sequential model that preceded it. On that question, the S4 program is offering a fairly clear answer.