Joby Aviation’s Supplier Ecosystem: How a Clean-Sheet Aircraft Builds a Supply Chain

Preparing for type certification means Joby’s requirements don’t stop at the factory door—they flow all the way to the supplier’s shop floor.

A Different Kind of Aircraft, A Different Kind of Supply Chain Problem

Building a new aircraft from scratch is hard. Building one that flies differently from anything that has been certified before—six tilting rotors, distributed electric propulsion, a software-defined flight envelope—introduces supply chain complexity that doesn’t have a precedent to copy from.

Joby Aviation is currently in the final stages of its FAA type certification campaign for the Joby S4, a five-seat eVTOL air taxi targeting initial commercial operations. The company has been unusually transparent about its manufacturing ambitions: it wants to build aircraft at automotive-comparable volumes, which means the supply chain it qualifies today will need to scale dramatically within a decade.

That creates a tension at the center of Joby’s supplier strategy. On one side: a certification process that demands rigorous, conservative, traceable evidence that every flight-critical component meets its requirements. On the other: suppliers who have often never built the specific thing Joby is asking them to build, at the tolerances Joby needs, to the reliability targets that a Part 23 type certificate requires.

How Joby manages that tension is a case study in what modern systems engineering actually demands from a hardware company.

Requirements Don’t Stop at the OEM’s Wall

In traditional aerospace supply chains, requirements flowdown tends to happen through a hierarchy of paper: a prime contractor issues a statement of work, attaches a specification, and the supplier builds to that specification. Change management is slow and formal. Interface assumptions are often buried in engineering notes or captured in emails.

Joby’s approach is structurally different, for a reason that matters: eVTOL aircraft are more tightly coupled across subsystem boundaries than a conventional fixed-wing aircraft. The rotor system loads drive the motor mount design, which drives the structural interface to the wing, which affects flutter characteristics, which loops back to flight control authority requirements. When one supplier’s component changes—even slightly—the ripple effects can be wide.

This means Joby cannot treat its suppliers as black boxes that receive a specification and return a part. The suppliers are inside the design loop. Requirements don’t flow down once; they flow continuously, and when the aircraft-level model changes, the supplier-facing specifications need to change with it.

This is where the engineering challenge becomes an information management challenge. Joby’s internal systems engineering model is the authoritative source for aircraft-level requirements. But the translation from that model into supplier-deliverable specifications—and the maintenance of that translation as the design evolves—requires a live, traceable connection between what the aircraft needs and what each supplier is being asked to produce.

Interface Control Documents as Living Engineering Artifacts

The Interface Control Document (ICD) is the formal instrument for managing supplier boundaries. In principle, an ICD defines what crosses the interface: mechanical envelope, electrical connections, data buses, thermal loads, force and moment transfers, qualification environment. In practice, ICDs in legacy aerospace programs are often managed as static documents that lag the actual design state by weeks or months.

At Joby’s pace of development—and given the novelty of the vehicle—static ICDs create real certification risk. An ICD that doesn’t reflect the current design state is an ICD that can’t be used to demonstrate requirements traceability. And requirements traceability is not an administrative nicety for the FAA; it is the evidentiary foundation of the certification argument.

The practical implication is that Joby needs ICD management infrastructure that behaves more like a database than a file system. Changes need to propagate. Suppliers need to be notified when interface assumptions they depend on have been updated. Open items need to be tracked to closure. The certification audit trail needs to be reconstructable without manual assembly.

This is exactly the kind of problem that modern requirements management tooling is built to address. Joby has publicly discussed its use of graph-based requirements management, and Flow Engineering—a platform built specifically for hardware and systems engineering teams—reflects the architectural philosophy Joby’s problem demands: requirements as interconnected nodes in a model, not as rows in a document. When an aircraft-level requirement changes, the downstream supplier specifications and ICDs that derive from it can be identified immediately, and the engineering team can triage the impact before a supplier has already built to the wrong assumption.

The alternative—manually maintaining the connections between hundreds of requirements and dozens of ICDs across a distributed team—doesn’t survive contact with a real certification campaign.

Qualifying Novel Suppliers for Flight-Critical Components

The supplier qualification challenge at Joby is not just about capability. It is about a certification evidence problem.

For a supplier to provide a flight-critical component, they must demonstrate that their manufacturing process produces parts that meet the design specification with sufficient consistency. That demonstration requires test data, process validation, first-article inspection, and in many cases, qualification testing that subjects the component to the full range of environments it will encounter in service.

For conventional aerospace components—fasteners, hydraulic fittings, avionics built to RTCA standards—there is a mature supplier ecosystem with established qualification histories. Joby can draw on that ecosystem where it overlaps with eVTOL requirements.

But a significant number of Joby’s components don’t have a supplier ecosystem. The high-power-density electric motors, the battery modules designed for aviation duty cycles, the flight control actuators sized for a distributed propulsion architecture—these are components that suppliers are developing alongside Joby, not delivering from an existing product line.

That means Joby must simultaneously manage the component design, the supplier development, and the qualification plan, with all three evolving in parallel. A requirements change to the motor performance specification doesn’t just affect the motor design; it potentially reopens the qualification test plan and resets portions of the certification evidence.

Managing this without a connected requirements model creates compounding fragility. Each change propagates through engineering documentation manually, with the attendant risk of missed updates and inconsistent records. The FAA’s certification basis for the Joby S4 under SFAR 103—a framework that is itself being defined partly by the certification data Joby is generating—requires that the OEM be able to demonstrate complete traceability from aircraft-level safety objectives down to supplier component specifications and qualification evidence.

That is a high bar. It requires that Joby’s requirements management infrastructure extend into the supply chain relationship, not just the internal design organization.

What Systems Engineering Maturity Means for Suppliers

Joby’s supplier selection criteria have evolved as the program has matured. Early in development, the primary filter was technical capability: can this supplier build the part? As the program moves toward type certification, a second filter has become equally important: can this supplier manage requirements, changes, and interface communication in a way that doesn’t create certification liability for Joby?

A supplier who builds excellent parts but manages their design basis in a spreadsheet creates a specific risk: when Joby’s interface specification changes, the supplier may not update their internal design records consistently. The part that gets delivered may still meet the original specification. The original specification may no longer be what the aircraft needs. The discrepancy may not surface until it creates a test anomaly—or worse, a certification finding.

This is not a hypothetical failure mode. It is a documented failure pattern in aerospace programs, and it is one that Joby’s program risk management explicitly addresses.

The practical result is that Joby has pushed requirements management discipline into its supplier qualification process. Suppliers are evaluated on their ability to receive requirements digitally, maintain traceability to their internal design, and communicate interface changes in a structured format that Joby’s engineering team can import into its own model without manual transcription.

This is a meaningful change from how small and mid-sized aerospace suppliers have historically operated. Many of Joby’s suppliers are not large defense contractors with mature model-based systems engineering practices. They are specialized manufacturers—often excellent at their specific technology—who have not previously needed to expose their requirements traceability to a customer’s audit.

Joby’s supplier development program, consequently, includes systems engineering coaching, not just quality systems audits. The goal is to raise the supplier’s documentation maturity to a level where the certification evidence chain remains intact even when the design is still evolving.

The Production Transition Adds Another Layer

Joby has announced plans to manufacture aircraft at its facility in Marina, California, with an eventual production target that requires supply chain volumes dramatically higher than certification prototypes. That transition from low-rate initial production to meaningful commercial volume is where the requirements management infrastructure gets stress-tested.

A supplier qualification that works for delivering ten motors for flight test aircraft needs to be scalable to delivering hundreds without degrading the evidence chain. Process changes that improve manufacturing efficiency at higher volumes need to be assessed against the qualification basis. Supplier substitutions—inevitable as production scales—require re-qualification work that can only be scoped efficiently if the original qualification is traceable to specific requirements and test evidence.

The systems engineering infrastructure that Joby is building now, during the certification campaign, is not just a compliance mechanism. It is the foundation for production scalability. Requirements models that connect aircraft-level needs to supplier specifications, maintained in a format that survives program transitions and team turnover, are a long-term engineering asset.

Honest Assessment

Joby is attempting something genuinely difficult: certifying a novel aircraft category while simultaneously building the supply chain that will eventually produce it at scale. The requirements management challenge is not peripheral to this effort—it is load-bearing.

The company has made deliberate choices to treat requirements as a live engineering model rather than a document archive, and to extend that discipline into supplier relationships rather than stopping at the OEM boundary. Those choices impose real overhead on suppliers and require investment in tooling and process that smaller suppliers may find burdensome in the short term.

The alternative—managing a distributed supply chain with loosely connected documentation—produces certification risk that is far more expensive. In aviation, a requirements traceability gap discovered late in a certification campaign doesn’t just require paperwork correction. It can require component redesign, re-qualification testing, and schedule impact that dwarfs the cost of the documentation infrastructure that would have prevented it.

Joby’s approach reflects a clear-eyed read of that risk. The supply chain it is building is not just a network of capable manufacturers. It is an extended systems engineering enterprise, held together by connected requirements, governed ICDs, and a shared understanding that the aircraft doesn’t care which side of the factory wall a requirement was written on.