Before the First Wrench Turns: How MRO Organizations Are Shaping eVTOL Certification

The classic sequence in aircraft development runs something like this: engineers design the system, certifiers approve it, operators buy it, and maintainers figure out how to keep it flying. The eVTOL sector is, by necessity, disrupting that sequence. Companies preparing to support novel electric vertical takeoff and landing aircraft are showing up earlier in the design process than any MRO organization has traditionally appeared—and the systems engineering community is starting to understand why that matters.

Latitude Aero, a North Carolina-based MRO provider that has positioned itself specifically to support the advanced air mobility sector, represents the leading edge of this shift. The company has been engaged in conversations with eVTOL OEMs not at entry into service, but during design review cycles. That positioning is deliberate, and it reflects a hard lesson the aviation industry learned with composite airframes in the 1980s and 1990s: if you do not write maintainability into the system architecture early, you spend the next thirty years performing maintenance that was never supposed to exist.

The Structural Problem with No Operational Heritage

Every airworthiness limitation in a traditional aircraft’s approved maintenance program traces back, ultimately, to something that happened in service. An inspection interval for a fatigue-critical structural element is grounded in material testing, yes, but it is calibrated against operational data—load spectra from real routes, failure modes observed in real fleets, service difficulty reports accumulated over years or decades. The interval reflects not just what the physics predicts but what the world has actually demonstrated.

eVTOL programs have none of that. A company pursuing type certification for a distributed electric propulsion aircraft with twelve lift rotors and a fly-by-wire flight control system is writing its Airworthiness Limitations Section (ALS) from first principles. The physics of lithium-ion cell degradation under cyclic load is understood in laboratory conditions. The fatigue behavior of carbon fiber rotor hubs can be modeled. But the actual failure mode distribution of a twelve-rotor system operating fifty revenue cycles per day in urban air corridors, across seasonal temperature variation, across pilot population variability—that data does not exist.

This creates a specific systems engineering problem: how do you write a requirement for an inspection interval when you cannot validate that interval against service experience?

The answer that is emerging from programs currently in certification is a combination of approaches. First, physics-based life limits—deriving inspection thresholds from material fatigue models with conservative factors, then treating those thresholds as provisional pending fleet data. Second, condition monitoring architectures—building sensor networks and prognostics into the aircraft not as optional features but as structural requirements, so that the aircraft generates the operational heritage it lacks historically. Third, staged ALS construction—filing an initial ALS based on conservative analysis, with explicit provisions for revision as operational data accumulates under an approved data collection program.

None of these approaches is unprecedented in aviation. What is unprecedented is applying all three simultaneously to an entirely novel category of aircraft, across propulsion, structure, avionics, and power systems, in parallel with the type certification effort itself.

What the MRO Community Actually Brings to Requirements

The value an MRO organization provides in early design engagement is not primarily about tooling or hangar capacity. It is about failure mode literacy. A maintainer who has spent years troubleshooting conventional aircraft develops an intuition for where systems fail in practice—not where they fail in FMEA, but where they actually fail when they encounter the real world.

That intuition, when brought into a design review, changes requirements. Latitude Aero’s engagement model with eVTOL OEMs has reportedly focused on several specific areas: access for inspection, connector standardization, component replaceability versus repair philosophy, and the diagnostic information architecture that maintenance technicians will actually need to troubleshoot faults in the field.

Access for inspection sounds obvious, but it is routinely underspecified in early design. A system engineer designing a motor controller is focused on thermal performance, EMI compliance, and interface definitions. The question of whether a technician can reach the cooling system’s fluid connections with standard tooling after the aircraft has been in service for six months—with wiring looms installed, fairings in place, and all the other systems occupying the same space—is a different kind of question. It requires a different stakeholder to ask it.

Connector standardization is similarly unglamorous but consequential. eVTOL aircraft are being designed with high-voltage power distribution architectures that have no established connector standards in aviation. Different OEMs are making different choices. An MRO ecosystem that must support multiple platforms cannot carry infinite connector tooling inventory; the choices made by individual OEMs in their connector specifications will shape whether an efficient MRO ecosystem can develop at all. This is not just an MRO problem—it becomes a regulatory problem if the connector ecosystem is fragile enough to affect airworthiness.

The repair-versus-replace philosophy question has direct certification implications. Aviation traditionally prefers repair when possible, because replacement requires configuration control and parts availability that creates fleet management burden. But eVTOL propulsion components—electric motors, motor controllers, battery modules—may be better candidates for replacement rather than repair, both because their internal complexity makes repair difficult and because their failure modes are better characterized by cycle counts than by physical damage. Writing a requirement for “replace motor assembly upon exceeding 2,000 flight cycles or detection of Fault Code 0x4A3” is a different kind of requirement than “inspect motor brushes per AMM Section 72-20.” Both are maintenance requirements. They require different documentation structures, different parts logistics, and different technician qualification pathways.

The Maintenance Review Board Process as Requirements Leverage Point

The Maintenance Review Board (MRB) process is where maintenance requirements get formally structured for certificated aircraft. An MRB report, approved by the FAA or relevant authority, establishes the initial scheduled maintenance requirements—the foundation from which operators build their approved maintenance programs. For novel aircraft categories, the MRB process is also where the absence of operational heritage becomes a regulatory negotiation.

The MRB process traditionally involves the OEM, the certifying authority, and representatives of operator and MRO communities. For eVTOL programs, the MRO community’s participation in that process has become more substantive than the industry norm—because the normal calibration mechanism (service experience) is absent, and someone has to provide the practical judgment that would otherwise come from fleet data.

MRO organizations that have engaged early in eVTOL programs are arriving at MRB meetings with documented analysis rather than just practitioner opinion. They have conducted teardown studies on electric motor assemblies from analogous industries. They have modeled battery module replacement workflows against candidate aircraft architectures. They have identified, in advance, which maintenance tasks will require specialized equipment that does not exist in current MRO infrastructure—and that identification, made early enough, gives OEMs the opportunity to design toward standard tooling rather than requiring novel ground support equipment at entry into service.

This is a meaningful shift in how requirements flow. Traditionally, the MRO community’s influence on requirements was largely reactive: the aircraft was designed, the ALS was drafted, and maintainers commented during the review period. The eVTOL context is producing a different pattern, where MRO-derived constraints are entering the requirements baseline early enough to actually affect system architecture decisions.

Where Systems Engineering Practice Has to Change

The systems engineering discipline has well-established methods for maintainability analysis: Maintenance Task Analysis (MTA), Level of Repair Analysis (LORA), and reliability-centered maintenance (RCM) are all mature methodologies with established practice in aerospace. The problem is not that these methods do not exist. The problem is that they are frequently applied too late in the development cycle to influence the decisions that matter most.

An MTA conducted after the system architecture is frozen can identify maintenance burden but cannot reduce it. A LORA that determines field replacement is preferred over depot repair is useful only if the system was designed with field-replaceable units—which requires that the LORA was at least roughly anticipated during architecture development. RCM analysis that identifies a critical function with no fault detection capability is a finding that has limited value after the relevant hardware is in production.

The systems engineering community is, slowly, internalizing this sequencing problem. The pressure from eVTOL certification timelines is accelerating the internalization, because the stakes of getting it wrong are particularly high. A type certificate is not the finish line—it is the starting line for a maintenance program that will determine whether the aircraft remains airworthy in revenue service. An aircraft that is technically certificated but practically unmaintainable because its inspection access is poor, its fault codes are uninformative, and its replacement parts are unavailable in the supply chain is an aircraft that will not survive in commercial operation.

Requirements management in this environment has to support tighter coupling between design requirements and maintenance requirements than traditional practice provides. A propulsion system requirement that specifies motor efficiency thresholds without specifying the diagnostic observability needed to detect efficiency degradation in service is incomplete—not from a certification standpoint, but from an operational standpoint. The systems engineering tools and processes that connect those two requirements, trace the relationship between them, and surface gaps during design reviews are doing work that directly affects airworthiness outcomes.

Modern graph-based requirements management platforms—tools like Flow Engineering that represent requirements and their relationships as interconnected models rather than flat document hierarchies—make this kind of cross-domain traceability tractable at scale. When a maintenance engineer can navigate from a high-level airworthiness objective through the system architecture to the specific sensor specification that enables the relevant condition monitoring, and can see that chain clearly during a design review, the conversation about completeness becomes more productive. The alternative—reconstructing that chain from multiple disconnected documents during an MRB meeting—produces findings that are too late to be cheap to fix.

The Honest Assessment

The eVTOL sector is attempting something the aviation industry has not done before at this scale and pace: certifying an entirely novel aircraft category, across multiple competing platforms, without the operational heritage that has historically anchored the maintenance program development process. The MRO community’s early engagement with these programs is a rational response to that challenge, and it is producing better requirements in programs where it is happening.

But the engagement is uneven. Some OEMs are actively soliciting MRO input at PDR. Others are still treating maintainability as a downstream concern. The difference in requirements quality between those two approaches will not be fully visible until aircraft are in revenue service and maintenance organizations are executing the approved maintenance programs—at which point fixing the problems becomes expensive in ways that early engagement would have made cheap.

The systems engineering community’s role in this is not to replace MRO expertise with analysis tools, but to create the structural conditions in which that expertise can be brought to bear early enough to matter. That means building maintainability requirements into the requirements baseline from the beginning, tracing them through the system architecture, and treating the absence of operational heritage not as a reason to defer the problem but as a reason to be more rigorous about the analytical foundations that must substitute for it.

The wrench turns eventually. The question is whether the system it encounters was designed with that moment in mind.