
What Is MRO in Aviation — and Why the Definition Matters
Most definitions of MRO are technically correct and practically useless.
Maintenance, Repair and Overhaul: the set of activities that keep an aircraft airworthy. You find this in industry glossaries, analyst reports, and the opening slides of vendor presentations. It describes what MRO involves. It says almost nothing about what MRO is — why it is structured the way it is, who is accountable for what, and why the decisions made inside an MRO operation carry consequences that extend well beyond the hangar.
The problem is not that the standard definition is wrong. It is that it frames MRO as a collection of activities when MRO is a system — one with a specific regulatory logic, a defined organizational structure, and a set of responsibilities that interact in ways the activity-based definition does not capture.
Understanding what MRO actually is requires starting from a different question. Not what activities it involves, but what the system is designed to guarantee.
The Standard Definition — and Where It Falls Short
The standard definition treats MRO as a technical function. Scheduled inspections. Engine overhauls. Component repairs. Line checks. This is accurate as far as it goes, but it describes the outputs of MRO without explaining the logic that produces them.
MRO is not a category of technical work. It is the system by which an operator maintains the right to fly.
Airworthiness is not a state you achieve once and then retain. It degrades — through use, age, and the accumulation of unresolved items. Every flight adds cycles and hours to every component. Every deferred defect becomes part of the record. Every limit that approaches must be tracked and acted on before it is exceeded. MRO is the continuous process of keeping an aircraft within the bounds of what its type certificate, approved maintenance programme, and applicable regulatory requirements allow.
That definition has a different center of gravity. It places obligation before activity. And it makes the scope of MRO considerably harder to reduce to a shorthand.
It is not a maintenance function. It is a continuous demonstration of airworthiness, expressed through maintenance.
Three Disciplines, Three Different Problems
What gets called MRO actually contains three distinct disciplines. Treating them as variations of a single activity is the error that produces most of the confusion in how MRO is described, bought, and managed.
Line maintenance is the work performed between flights — turnaround checks, pre-flight inspections, defect rectification, minor scheduled tasks. It happens on the ramp, under time pressure, with the next departure in view. The defining constraint is availability: the aircraft must be serviceable for the next flight. Decisions in line maintenance are made quickly, often with incomplete information, by engineers who may not have immediate access to the full maintenance history.
Base maintenance is the heavier scheduled work — the checks that take an aircraft out of service for days or weeks. It happens in a hangar, with full access to the airframe, governed by the aircraft's approved maintenance programme (AMP), which is derived from the manufacturer's maintenance planning document (MPD). The defining constraint is completeness: every task in scope must be accomplished or formally deferred within approved limits. The record produced by base maintenance is the primary evidence of compliance.
Component maintenance covers the overhaul and repair of parts removed from the aircraft — engines, landing gear, avionics, actuators, flight control surfaces. It happens at specialist facilities, often geographically distant from the operator's base, on planning horizons measured in months rather than days. A component removed today may not return for six months. Its status throughout that interval is part of the operator's continuing airworthiness picture.
These three disciplines have different regulatory approval requirements, different workforce qualification standards, different documentation frameworks, and different organizational structures. Software designed around one of them will not serve the others without significant compromise. The category error of treating them as one thing propagates into every downstream decision about how MRO is managed and how tools are built for it.
Who Is Actually Responsible for MRO?
Most definitions of MRO imply that it is something an airline or a maintenance organization does. The regulatory structure is more layered than that — and understanding it is a prerequisite to understanding what MRO data means and who needs to see it.
The operator holds the Air Operator Certificate (AOC) — the authorization issued by their national civil aviation authority to conduct commercial air transport. That certificate is conditional. One of its core conditions is the continuing airworthiness of every aircraft in the fleet. The operator is ultimately responsible for this, regardless of whether it performs the maintenance itself or contracts it to external organizations.
In practice, most operators separate the two functions that sit beneath that responsibility. The physical maintenance work is performed by a Part-145 approved maintenance organization — the European regulatory framework for organizations certified to carry out and certify maintenance work on commercial aircraft. This approval can be held by the operator itself or contracted to a third-party facility.
The continuing airworthiness management function is held by a Continuing Airworthiness Management Organization, operating under Part-CAMO. The CAMO does not perform maintenance. Its role is to own and maintain the airworthiness picture: planning the maintenance programme, monitoring compliance with applicable requirements, managing open defects, tracking component status, and ensuring the records for each aircraft are complete and current.
The result is a three-party structure — operator, CAMO, Part-145 organization — with separate approvals, separate responsibilities, and separate signing authorities. The CAMO certifies continuing airworthiness. The Part-145 organization certifies the maintenance work. The operator is accountable for both, through approvals it either holds internally or contracts to external parties.
This structure is not a regulatory formality. It exists because the responsibilities are genuinely distinct, require different technical competence, and need independent oversight. It also determines how data should flow in any system that supports MRO. The CAMO needs visibility into maintenance activity without holding the authority to certify it. The Part-145 organization needs to record and sign off on completed work without managing the broader airworthiness picture. These are different data needs, different access levels, and different signing authorities — all within what is commonly described as a single MRO operation.
What Continuing Airworthiness Actually Means
Continuing airworthiness is the framework that underlies all of MRO — and the concept most industry definitions skip entirely.
An aircraft's type certificate defines the conditions under which that aircraft design is considered airworthy. But a specific aircraft, operated over time, diverges continuously from its certified baseline. Hours and cycles accumulate against every time- and cycle-limited component. Airworthiness Directives (ADs) — mandatory safety instructions issued by authorities when an unsafe condition is identified on a type — add requirements that must be incorporated into the maintenance programme. Service Bulletins (SBs) from manufacturers recommend modifications and inspections that may be made mandatory by authority action. The AMP evolves as the aircraft's configuration changes and as the applicable requirements accumulate.
Continuing airworthiness is the discipline of keeping a specific aircraft in conformity with all of this — not just the scheduled maintenance programme, but the complete and current picture of what applies to that aircraft, on that day, given its entire operational history.
The CAMO owns this picture. Its job is not to plan maintenance in the abstract. It is to know, at any given moment, the exact compliance status of each aircraft in its care: what is due, what has been deferred within approved limits, what remains open, and what has been accomplished and recorded.
This is why the record is not administrative overhead. The record is the mechanism by which continuing airworthiness is demonstrated. A gap in the record is not a documentation problem — it is an airworthiness problem.
The Record as the Primary Output
There is a common misconception about what MRO produces. The visible output is a maintained aircraft. The record is less visible, and so it tends to be treated as secondary — something that follows the work, rather than something that is constitutive of it.
This framing is wrong, and it shapes how MRO is managed and how software for it is built.
The record is not a report of what was done. It is the demonstration that the work was carried out correctly, by appropriately qualified personnel, using approved data, in compliance with the applicable requirements. Without a complete and accurate record, the maintenance cannot be considered to have occurred in a regulatory sense. The airworthiness cannot be demonstrated. An authority audit does not assess whether the maintenance happened — it assesses whether the record shows that it happened correctly.
This means every decision in MRO has two dimensions: the physical dimension (was the task performed correctly?) and the documentation dimension (does the record accurately reflect what was done, by whom, using what approved data?). Both are required. Neither is sufficient alone.
It is not maintenance and records. It is maintenance as records.
How MRO Looks Different by Operator Size
The way MRO is structured varies significantly by operator type — and this variation is poorly represented in standard market definitions that treat MRO as a single category.
Large airlines typically consolidate the CAMO function, Part-145 maintenance capability, and fleet management within a single organization. Their MRO operation is vertically integrated, supported by large technical departments, and built on systems that assume significant internal bandwidth. The information flows are mostly internal. The approvals sit within the same organization. Data does not need to move between entities.
Smaller operators — regional carriers, charter operators, business aviation fleets — typically rely on third-party Part-145 organizations for most or all of their maintenance. The CAMO function may be internal or externally contracted. The three-party structure is external rather than consolidated. Data generated at a third-party maintenance facility must reach the CAMO. The CAMO must update the operator's records. Those records must be accessible to the authority on request. Each of those transfers is a point where information can be delayed, inconsistently recorded, or lost.
This is not a smaller version of large-airline MRO. It is a structurally different problem — with more external dependencies, more complex information flows between organizations that hold separate approvals, and significantly less internal resource to manage the coordination. Describing both with the same definition obscures the differences that actually determine what tools and processes will work.
What This Means for MRO Software
MRO software exists, in principle, to manage the record: to store the right information, make it accessible to the right people, and surface the right actions when tasks fall due or limits approach.
Whether a given system does this well depends on whether its design reflects the actual structure of the operation it serves. A system built around the large-airline model — Part-145 held internally, CAMO integrated within the same organization, all data in one place — will not fit an operation where those functions are held by separate entities with separate approvals. The data model will not match the regulatory structure. The workflow will not reflect who is authorized to certify what.
The CAMO and the Part-145 organization may look at the same record, but they certify different things and carry different authority. A unified record is not the same as a merged record. The distinction matters — and software that collapses it produces a record that does not accurately represent how the approvals actually work.
The question that matters for any MRO system is not what features it offers. It is whether the structure of the software matches the regulatory and organizational structure of the operation it is meant to support.
Getting that right is the design problem most MRO software has not yet solved.

.png)



