Joby Aviation’s Supply Chain Engineering Challenge: What Certifying a New Powertrain Ecosystem Actually Requires

When Joby Aviation received its FAA Part 135 Air Carrier Certificate in 2023 and continued advancing toward its Part 21 type certificate, most coverage focused on the aircraft itself — the six-tilt-rotor configuration, the 200-mile range claim, the noise profile. Less attention landed on the harder, slower, less photogenic problem underneath all of that: Joby is qualifying hardware that has never been manufactured at production scale, from suppliers who have never built it before, against standards that are still being written.

That is not a criticism. It is a precise description of what certifying a genuinely novel propulsion architecture requires. And the systems engineering infrastructure required to do it cleanly is one of the most underexamined challenges in the advanced air mobility sector.

The Baseline Problem: There Is No Existing Supply Base

Conventional aircraft programs inherit a supply base. A new narrow-body jet draws on decades of qualified titanium forgings, certified avionics suppliers, and turbofan vendors whose manufacturing processes the FAA has seen many times. The certification team is still working hard, but they are working within a known space of supplier capabilities and failure modes.

Joby’s powertrain sits outside that space on almost every dimension.

The aircraft uses six electric motors — each capable of both lifting and forward thrust through tilt — connected to lithium-ion battery packs that must deliver high discharge rates across an expected 15-minute to 60-plus-minute mission profile, managed by motor controllers and inverters that must maintain functional safety under conditions (rotor wash, vibration spectrum, thermal cycling) that no previous inverter qualification program has addressed directly. The rotor assemblies themselves are composite structures optimized for an acoustic target — 65 dB at 100 meters — that required blade geometry and tip-speed choices with no prior certification precedent.

None of the vendors supplying those components walked in with a qualified part. They walked in with a capability, and the qualification had to be built jointly. That changes the nature of requirements flowdown entirely.

How Requirements Flowdown Works — and Where It Breaks for Novel Hardware

In a mature program, requirements flowdown is fundamentally a translation exercise. The aircraft-level requirement (“the fuel system shall sustain engine operation during 45 seconds of inverted flight”) maps to a component-level requirement (“the fuel pump shall maintain positive flow at negative 1g for 45 seconds”), which maps to a supplier manufacturing process requirement. At each level, there is usually a body of regulatory material — an FAA Advisory Circular, an SAE Aerospace Recommended Practice, a MIL-SPEC — that tells the design team what “good enough” looks like.

For Joby’s powertrain, that body of material is thin, incomplete, or simply absent.

FAA Special Conditions for electric propulsion are being developed in parallel with the aircraft being certified. The agency has issued Special Conditions for Joby’s aircraft (SC-VTOL-01) that address some propulsion requirements, but those documents themselves acknowledge that equivalent safety must be argued rather than demonstrated against a pre-existing standard. Joby must work with the FAA to establish what the battery system requirements actually are — maximum charge state, thermal runaway containment, state-of-health monitoring — and then flow those down to a cell supplier and pack integrator who are also, in some cases, developing their processes in real time.

This creates a bidirectional requirements problem. The supplier’s demonstrated capability informs what the aircraft-level requirement can practically be. The aircraft-level requirement informs what the supplier must achieve. The two are not independent, and the certification basis sits at their intersection. Managing that negotiation rigorously — with traceability intact — is a systems engineering function, not a program management one.

The risk of getting this wrong is not abstract. If the battery pack thermal runaway containment requirement is written to match what the supplier can currently build rather than what the aircraft safety case genuinely requires, the certification basis is compromised. The FAA’s Aircraft Certification Service has flagged this category of risk explicitly in guidance material on novel and unusual design features.

Interface Control in a Novel Powertrain: Interdependent Failure Modes

In a gas turbine aircraft, the engine is a certified unit. The airframer specifies thrust, fuel consumption, dimensional envelope, and mounting loads; the engine OEM certifies the internals. The Interface Control Document defines the boundary and the two teams work on their respective sides of it. Failure modes in the engine are the engine manufacturer’s problem, within that boundary.

Joby’s powertrain does not permit that clean decomposition.

A motor controller failure can induce rotor behavior that creates structural loads the rotor hub was not designed to see. A battery state-of-health estimation error can cause the flight management system to command a maneuver that exceeds the motor’s peak thermal limit. An inverter switching frequency artifact can produce electromagnetic interference that affects the flight control sensors. These are not independent failure modes — they are failure modes where the cause is in one subsystem, the propagation path runs through the interface, and the effect appears in a third subsystem that the supplier of the first component never modeled.

That means Interface Control Documents for Joby’s powertrain components must carry functional safety content, not just dimensional and electrical specifications. The ICD between the battery pack and the motor controller is not just a connector pinout and a voltage range. It must define the state machine at that interface — what happens when the BMS declares a cell string fault, what the motor controller must do in response, what the flight management system must be told, and in what time window. Each of those behaviors needs a requirement, a verification method, and a test.

Multiply that across six motors, six inverters, six rotor assemblies, and a battery architecture that likely involves multiple parallel pack strings, and the interface management problem becomes the program’s central engineering coordination challenge.

Publicly available materials — including Joby’s investor disclosures and FAA docket submissions — indicate the company has invested heavily in vertical integration for exactly this reason. By manufacturing the motor and motor controller in-house, they eliminate one ICD boundary and the associated failure mode propagation complexity. But vertical integration is not unlimited; the battery cells, certain structural composites, and avionics hardware involve external suppliers, and those boundaries require the full rigor of managed interfaces.

Engineering Collaboration Infrastructure as a Certification Artifact

Here is the part that rarely appears in industry coverage: how Joby exchanges information with its suppliers is not a program administration question. It is a certification question.

When the FAA audits a type certificate, it is examining whether the applicant can demonstrate compliance with its certification basis. Part of that demonstration involves showing that the requirements the supplier was given were correct, complete, and flowed down from the aircraft-level safety requirements in a traceable way. It involves showing that design changes were evaluated against the requirement set before they were incorporated. It involves showing that test data from supplier qualification programs was reviewed against the right acceptance criteria, and that discrepancies were dispositioned properly.

If those exchanges happened in email threads, shared drives, and PDF markups, reconstructing the audit trail is expensive and error-prone. Worse, it creates conditions where a supplier change that should have triggered a re-evaluation of the interface requirement simply doesn’t — because no one in the system noticed that the change touched a parameter that was constrained by a higher-level requirement.

This is where the infrastructure of requirements management becomes load-bearing. The question is not whether to track requirements — no serious aerospace program skips that step. The question is whether the system can maintain live traceability between the aircraft-level safety requirement, the supplier’s component requirement, and the test evidence, across an extended supplier base, through design iterations that occur over a multi-year certification campaign.

Legacy requirements management tools — IBM DOORS and its successors, Jama Connect, Polarion — were built for a world where requirements are largely stable documents exchanged between an OEM and a mature supplier. They are capable tools for that context. The challenge in a novel program like Joby’s is that requirements are not stable. They evolve as the safety case is argued with the FAA, as supplier test results reveal new failure modes, as design changes cascade across interfaces. Document-centric approaches struggle with that dynamism because they were not designed to handle requirements as nodes in a live graph where a change to one node propagates visibly to dependent nodes.

This is the operational gap that graph-based, AI-native requirements platforms are designed to close. Tools like Flow Engineering, built specifically for hardware and systems engineering teams, approach requirements as structured, interconnected models rather than document hierarchies. In a program context where the requirements themselves are under active negotiation — with the FAA, with suppliers, across internal subsystem teams — the ability to trace change impact automatically, identify which supplier specifications are affected when an aircraft-level safety requirement is revised, and maintain a live picture of coverage gaps, is not a luxury feature. It is the mechanism by which the certification audit trail stays coherent.

For a program like Joby’s, the collaboration infrastructure question is: can a supplier’s design team see, in real time, which of their requirements are derived from which aircraft-level safety goals? Can a change to the battery thermal runaway requirement propagate visibly to the motor controller ICD? Can an engineer on the rotor team identify that a blade geometry change affects a noise requirement that flows down to a certification basis document? That level of live, connected traceability is what modern requirements tooling is increasingly expected to deliver.

The Broader Lesson for Advanced Air Mobility Programs

Joby is the furthest-along eVTOL program in the FAA certification pipeline, but it is not the only one. Archer Aviation, Lilium’s successor programs, Overair (before its closure), and Wisk Aero are all working through variants of the same problem: novel powertrain architectures, thin regulatory precedent, suppliers who have not previously built to aerospace quality standards for this class of hardware.

The programs that are struggling most with schedule and cost are, in most cases, struggling because the systems engineering infrastructure was treated as a support function rather than a core competency. Requirements were written late, flowed down informally, and supplier interfaces were managed through document exchange rather than through structured models. When the FAA asked for compliance evidence, the assembly cost was high — and in some cases, gaps were found that required design changes, restarting portions of the supplier qualification campaign.

The practical implication is direct: supplier qualification for novel hardware is a systems engineering problem. It requires a certification basis argued from first principles, requirements flowed down with explicit traceability, interfaces managed with functional safety content, and collaboration infrastructure that can survive multiple years of design iteration without losing its audit trail.

Joby’s investment in vertical integration, in-house motor development, and close supplier collaboration is public record. The less visible investment — in the engineering coordination systems that make all of that traceable — is equally important. And for the programs that follow, getting that infrastructure in place before the supplier qualification campaign begins, rather than building it retroactively to support a certification audit, is probably the highest-leverage systems engineering decision the team will make.

The aircraft that eventually certifies will be notable. The engineering process that got it there will be instructive.