Inside Joby’s Supply Chain: What It Takes to Build a Certification-Ready eVTOL Ecosystem

Joby Aviation is building an aircraft that has never existed before. Its five-passenger, all-electric air taxi is designed to be quiet enough for urban operation, capable enough for commercial service, and safe enough to satisfy the FAA under Part 23 — the certification standard that governs light aircraft but has never been applied to a vehicle of this configuration and propulsion architecture.

Most of the coverage of Joby focuses on the aircraft itself: the tilting rotors, the distributed electric propulsion, the noise signature that makes urban operation plausible. Less examined is the industrial challenge underneath — the network of suppliers that Joby has assembled to build motors, battery systems, avionics, structural components, and the dozens of other subsystems that make the aircraft function. These are the companies doing the actual manufacturing. And for many of them, working to aviation standards is entirely new.

That novelty creates a specific kind of engineering problem that extends well beyond quality control. It is a systems engineering problem, a requirements management problem, and ultimately a certification evidence problem. How Joby is managing it — and what is working and what is not — carries direct implications for every other eVTOL program trying to build a certification-ready supply chain.

The Dual Novelty Problem

Suppliers to Joby face what engineers on the program call a dual novelty problem. First, the technology itself is novel. High-power-density electric motors designed for aviation duty cycles, battery systems that must meet both energy density and crashworthiness requirements simultaneously, fly-by-wire avionics for a redundant distributed propulsion system — none of these have well-established certification precedents. The FAA’s existing guidance, including AC 23.1309 for safety assessment and the means of compliance associated with Part 23 amendment 64, provides a framework, but it does not tell a motor supplier exactly how to demonstrate that their winding insulation system meets the intended function under the full envelope of thermal, vibration, and electrical stress conditions the aircraft will experience.

Second, the suppliers themselves are often novel to aviation. Several of Joby’s key suppliers entered the program with deep expertise in adjacent domains — automotive electrification, defense electronics, industrial composites — but without the organizational structures, documentation practices, or quality systems that aviation programs require. AS9100 certification is the floor, not the ceiling. The real requirement is the ability to produce, manage, and deliver technically correct, internally consistent, and FAA-defensible data packages that support Joby’s certification argument.

These two novelties compound each other. A supplier building a new class of hardware under a new regulatory framework, for the first time, inside an organization that has never done aviation development — that is a non-trivial engineering and organizational challenge.

What a Supplier Data Package Actually Contains

The term “supplier data package” understates what is actually required. For a safety-critical subsystem on a Part 23 aircraft, a complete data package is a structured body of evidence that includes design data (drawings, models, material specifications), analysis artifacts (stress analysis, thermal analysis, electromagnetic compatibility assessments, fault tree analysis, failure mode and effects analysis), test plans and test reports, configuration management records, and the requirements traceability matrix that shows how every allocated requirement from Joby’s system-level specification has been addressed and verified.

That last element — the requirements traceability matrix — is where many first-time aviation suppliers encounter their first serious difficulty. It is not enough to build hardware that works. The supplier must demonstrate, in a form that an FAA Designated Engineering Representative can audit, that every requirement levied on them by Joby has a corresponding verification event, and that the evidence from that verification event is complete, retained, and traceable to a specific configuration of hardware.

This is a documentation and process discipline problem as much as an engineering problem. A motor supplier who builds an excellent motor but cannot produce a traceable record of how thermal margin was verified under worst-case conditions has a certification problem, regardless of how good the hardware actually is. The FAA’s concern is not just that the aircraft is safe — it is that the applicant can demonstrate that the aircraft is safe through a structured, auditable argument. Suppliers are load-bearing nodes in that argument.

Interface Requirements: Where the Hard Problems Live

If individual subsystem data packages are difficult, interface requirements are harder. An eVTOL with distributed electric propulsion has a dense web of interfaces: the battery system supplies power to motor controllers, which command motor torques, which drive rotors whose aerodynamic outputs are coordinated by a flight control system, which monitors system health through sensors that feed into the vehicle management computer. Every one of those interfaces has to be specified, controlled, and verified.

Interface requirements documents — sometimes called IRDs or ICDs (Interface Control Documents) — define the agreed technical boundary between two subsystems. They specify electrical parameters, mechanical envelopes, data formats, timing constraints, and the failure modes that each subsystem must tolerate from the other. On a mature aircraft program, ICDs are living documents that accumulate decades of revision. On a first-of-a-kind vehicle with novel subsystems on both sides of every interface, they have to be written from scratch, often before either subsystem is fully understood.

The structural-thermal interface between a battery pack and the airframe is illustrative. The battery supplier needs to know what mechanical loads the airframe will impose on the pack under crash conditions, what thermal environment the pack will see during normal operation and in failure scenarios, and what structural margins the airframe expects the pack to maintain. The airframe supplier needs to know how the pack’s mass distribution changes as cells discharge, what thermal loads the pack will impose on adjacent structure, and what failure modes the pack might exhibit that could affect structural integrity. Getting those requirements right, in both directions, before either design is frozen, requires a level of cross-supplier coordination that is organizationally demanding and technically difficult.

Joby is managing this through a combination of system-level architecture control and a supplier integration process that treats ICDs as first-class program artifacts — not documentation artifacts to be produced after the fact, but engineering tools that drive design decisions in real time.

The Traceability Burden at Scale

Consider the scale of the traceability problem. A Part 23 aircraft certification program may involve tens of thousands of individual requirements distributed across dozens of subsystems and hundreds of supplier deliverables. Each requirement has a source (a regulation, a standard, a system-level design decision), an allocation (to a specific subsystem or component), a verification method (analysis, test, inspection, or similarity), and a verification record (a document, a test report, a signed DER finding). Keeping that structure coherent — ensuring that requirements don’t contradict each other, that every requirement is allocated to exactly the right level, that no requirement is lost as the design evolves — is a continuous engineering management challenge.

For suppliers new to aviation, this traceability burden is often the first serious organizational shock. The instinct of an experienced hardware engineer is to focus on the hardware. Certification programs require equal attention to the documentation chain. A requirement that was addressed in a test last year, using a slightly different hardware configuration, against a slightly different version of the specification, is not necessarily a valid verification event for the current design. The configuration management discipline required to maintain valid traceability across design changes, supplier changes, and specification updates is non-trivial.

The eVTOL industry is observing a consistent pattern: suppliers who invested early in requirements management tooling and process discipline are moving through Joby’s supplier qualification gates faster than suppliers who are trying to retrofit traceability onto a hardware-first development process.

What the Industry Is Learning

Several lessons are emerging from Joby’s supplier ecosystem that appear transferable to other eVTOL programs.

Requirements capability is a selection criterion. Joby and other leading eVTOL OEMs are increasingly treating a supplier’s demonstrated ability to manage and trace requirements as a qualification criterion alongside hardware performance. A supplier who can build to specification but cannot produce a defensible data package is a program risk, not an asset. This is shifting supplier selection conversations earlier — toward design readiness reviews and systems engineering capability assessments rather than prototype hardware performance alone.

Novel technology requires novel means of compliance. Where existing FAA guidance does not cover a specific technology or failure mode, the applicant must work with the FAA to establish an agreed means of compliance — a specific test program, an analysis method, or a combination of both. Suppliers need to understand that this process adds time and uncertainty to the schedule, and that the means of compliance negotiation is a systems engineering activity that requires supplier participation, not just OEM-level advocacy.

Interface requirements must be owned, not shared. On programs where ICDs are maintained informally or treated as bilateral supplier-to-supplier agreements, they tend to drift. The OEM must own the interface requirements as program artifacts, maintain configuration control, and treat interface changes the same way they treat changes to system-level requirements — with formal impact assessment and documentation.

Certification evidence is an engineering output, not an engineering afterthought. The most durable lesson from Joby’s supplier program is that evidence-building has to be planned as part of the design and development process from the beginning. Test plans that are written after hardware is built tend to verify what the hardware can do, not what the requirements say it must do. Certification programs require the reverse: requirements drive test plans, test plans drive test execution, and test results are interpreted against the original requirement, not against the hardware’s observed behavior.

The Broader Implication for eVTOL Programs

Joby is not alone in confronting these challenges. Archer, Lilium’s successor programs, Wisk, and a dozen other eVTOL developers are building supplier ecosystems with similar structural characteristics: novel hardware, first-time aviation suppliers, dense interface networks, and aggressive certification timelines. The supply chain problem is not unique to Joby — it is endemic to the eVTOL category.

What is emerging from the programs that are moving fastest is a model in which requirements management is treated as a core engineering competency, not a documentation function. Programs that have invested in structured requirements tools — tools that support bidirectional traceability, model-based interface definitions, and supplier data integration — are reporting fewer surprises at certification milestones. The surprise rate at design reviews and compliance audits is a leading indicator of program health, and it correlates directly with the rigor of the requirements management process upstream.

Modern AI-native requirements platforms like Flow Engineering are beginning to see adoption in this context — not as document management replacements, but as tools that help engineering teams maintain coherent requirement hierarchies across complex supplier networks, identify gaps in traceability before they become FAA findings, and manage the interface requirement problem at a level of granularity that spreadsheet-based approaches cannot sustain. The ability to model the requirement relationships between subsystems, and to surface inconsistencies before they propagate into hardware, is exactly what multi-supplier eVTOL programs need. Flow Engineering’s graph-based architecture, which treats requirements as connected nodes rather than rows in a table, maps naturally onto the interface-heavy structure of a distributed propulsion aircraft.

Honest Assessment

The eVTOL supplier ecosystem is maturing, but it is not mature. The programs that have been most transparent about their certification progress — including Joby — are discovering that the hardware development curve and the certification evidence development curve are not the same curve, and that closing the gap between them is an organizational challenge as much as a technical one.

The suppliers that will serve this industry well over the next decade are those who understand that delivering a working subsystem is necessary but not sufficient. Delivering a traceable, auditable, FAA-defensible case that the subsystem meets its allocated requirements — under all relevant conditions, across the full envelope, with configuration-controlled evidence — is what certification actually demands. Building that capability is the work that most of the industry still has ahead of it.