Logic, Data, and the Enterprise: Why AI in Aircraft Sustainment Starts Somewhere Other Than the Maintenance Shop
A question that sounds technical is in fact strategic: what does it take to make artificial intelligence useful in the sustainment of military aircraft?
The question is live because of an instinct now visible in the Pentagon’s approach to maintenance. Put simply, the instinct is that AI is a tool, and tools can be dropped into workplaces. Buy the software, hand it to the maintenance department, and readiness will follow. A recent NAVAIR draft request reflects that approach.
I think the approach starts in the wrong place. This article sets out why, and what a better sequence looks like, using the experience of Sikorsky, a Lockheed Martin company, and the CH-53K as a case study.
The Wrong Starting Point
Begin with what AI actually is. Strip away the marketing and an AI system is a logic system: it takes inputs, applies rules or learned patterns, and produces conclusions. The discipline of logic has a very old lesson for anyone who builds or buys such systems. A valid argument built on false premises yields conclusions that are perfectly well formed and perfectly wrong. Validity guarantees nothing about truth. Truth depends on the premises, and in maintenance the premises are data.
That is why dropping AI tools into a maintenance department is the wrong starting point. If the underlying records are incomplete, inconsistent, late, or locked in systems that do not talk to one another, the AI will process them faithfully. It will do so quickly and at scale and with an air of authority. You do not get better decisions. You get fast management of bad data.
The point is not that AI is oversold, though it often is. The point is that the outcome depends on two things that sit outside the algorithm. The first is good data: accurate, traceable to a specific part on a specific aircraft, and captured at the point where the work is done. The second is an enterprise built to act on what the data reveals: a supply chain, a contracting structure, and a set of incentives that turn an insight into a part on the shelf or a repair completed before the failure.
I have been making a version of this argument about the CH-53K for some months. The Kilo is a smart aircraft, a digital machine designed with supportability in mind, with software that can be upgraded over time. It is a poor bargain to place a smart aircraft inside a dumb enterprise. The platform’s intelligence is only as valuable as the ecosystem around it.
Two Targets for Artificial Intelligence
The most useful distinction I have found is between AI aimed at the aircraft and AI aimed at the industrial base.
Aimed at the aircraft, the family of tools includes condition-based maintenance plus (CBM+), fatigue damage monitoring (FDM), and the planned digital twin. The logic here is familiar to readers of this site. Instead of replacing a component after a fixed number of flight hours, whether or not it needs replacing, you measure the actual stress and load a component has experienced, tied to that component’s serial number, and replace it based on its real condition. Fatigue monitoring replaces a statistical guess with the history of the specific part. A digital twin extends the idea: a virtual model of the aircraft, updated with its real operating history, against which predictions can be run.
Aimed at the industrial base, the work looks entirely different. The object of attention is not a rotor blade but the system that makes and delivers rotor blades, along with the other thousands of parts an aircraft depends on: the suppliers, the lead times, the demand signals, the obsolescence risks, the inventory sitting in the wrong place. Here the tool I understand Sikorsky has built is called Ariel. As I understand it, Ariel was launched in July 2026, works with the Defense Logistics Agency, and covers more than 6,000 spare parts under the framework known as Captains of Industry.
These two applications are not competing. They are two halves of one problem. Predicting that a component will fail in 400 flight hours is worth little if the replacement part has a 14-month lead time and the supplier has not been told. An aircraft-facing AI tells you what is going to be needed. An industrial-base-facing AI tells you whether the enterprise can deliver it. A force that has only one of the two has half an answer.
What connects them, I suggest, are two things: the digital thread and performance-based logistics.
The Digital Thread and the Contract
The digital thread is the unbroken record that follows a part from design through manufacture, installation, operation, repair, and retirement. Without it, data from the aircraft cannot be reliably tied to data from the factory or the depot, and the AI has nothing coherent to reason over. With it, the aircraft’s real condition can be connected to the part’s real history and to the supplier’s real performance.
Performance-based logistics, or PBL, is the contractual half. A PBL contract pays the supplier for outcomes rather than activity. The history of PBL in Marine Corps heavy-lift support shows why this matters.
In November 2018 Sikorsky won a $717 million, four-year award from NAVSUP Philadelphia to sustain the Marine Corps and Navy’s CH-53E Super Stallion and MH-53E Sea Dragon fleets. The significance was in the structure. Traditional PBLs measure a contractor on supply response time and parts availability. This one added an aircraft availability metric, so that incentives followed improvements in the readiness of the aircraft and not only the delivery of parts.
The distinction sounds small and is not. A contractor paid for parts availability is rewarded for having parts in a warehouse. A contractor paid for aircraft availability is rewarded for having aircraft that fly, which gives it an incentive to reduce demand, to improve maintainability, and to find the cause of a failure rather than simply to supply the replacement. The 2018 award also added readiness-critical components, among them the main and tail rotor blades, the main gearbox, the main rotor head, and flight control components.
The data side of that arrangement was a tool developed by Sikorsky and NAVAIR at Patuxent River, the Fleet Common Operating Environment, described as the government version of Sikorsky’s commercial Customer Care Center. Its value was that it allowed the parties to link a specific change in parts to a measurable change in aircraft availability. That is exactly the connection an AI needs in order to learn anything.
I find this sequence instructive. The contract created the incentive, and the data environment came with it. The sophisticated analytics can be built on that foundation because the foundation makes them worth building. If this reading is right, the order matters: enterprise, then data, then AI. Not the reverse.
What Captains of Industry Teaches
The Captains of Industry label deserves a closer look, because it tells us something about the other side of the transaction.
The Defense Logistics Agency’s Captains of Industry arrangements are sole-source agreements that use performance-based outcomes to improve spare parts availability and the response time for orders. A 2021 audit by the Department of Defense Inspector General counted 13 such contracts at DLA Aviation with a combined estimated value of $55.6 billion. The audit is a sober read, and it is relevant to the argument for a reason that has nothing to do with AI.
The auditors found that DLA expected substantial savings from one set of Boeing line items but had not validated its estimates against actual performance, and may have overstated them through an inconsistency in how a cost recovery rate was handled. In a separate case, a contract lacked performance metrics, and the supplier’s on-time delivery rate fell to 53 percent against an objective of 90 percent before corrective action.
The lesson is that these long-term arrangements are only as good as the measurement behind them. A performance-based contract without trustworthy performance data is an act of faith. An AI system working across thousands of parts under such an arrangement will either sharpen accountability or conceal its absence, depending on the data beneath it.
More recently, Sikorsky and DLA have been working together in other forms. In July 2025 DLA awarded Sikorsky two contracts worth a combined $419.5 million for spare parts and support for H-60 and H-53 helicopters. The contracts are firm-fixed-price, sole-source, and requirements-type, with a five-year base period and a five-year option. An April 2024 DLA notice had targeted 2,961 parts. These are not Ariel, and I do not want to conflate them, but they show the long-horizon relationship in which investment in data quality pays off. A ten-year relationship supports that investment in a way a one-year purchase order never will.
Why It Matters Operationally
The Marine Corps is organizing itself around a concept I have called the impact force: a distributed, expeditionary force that must operate for defined periods in contested environments, far from the support structure it was built on. The Kilo is a central piece of that concept, because moving heavy loads between dispersed sites is what makes distribution possible. A distributed force cannot rely on a large, fixed logistics footprint. It needs to know in advance what will break, and it needs the right part to arrive in the right place before it does.
General Hedelund’s notion of putting a timestamp on a deployment makes this concrete. If you know a unit must sustain operations for a defined period, you can work backward. Which components are likely to reach their limits within that window? Which have long lead times? Which depend on a single supplier? Fatigue data tied to serial numbers answers the first question. A supply chain model of the Ariel type, if it works as I understand it, answers the others. The timestamp is the question that makes the two halves meet.
This is why I keep returning to the idea that sustainment is a combat function. The decision to place a part or a repair capability somewhere is a decision about how long a force can fight. Made with good data inside an enterprise able to act, it is an advantage. Made with bad data by a system that accelerates the error, it is a hidden vulnerability, and an adversary does not need to find it for it to hurt.
The Case Against the Tool-First Approach
Return, then, to the NAVAIR draft request and the instinct behind it. The motive is sound: maintenance departments are overburdened, and AI offers real help in reading the data they generate.
My concern is about sequence and ownership. A tool-first approach treats the maintenance department as the place where the problem lives. But much of the problem lives upstream and elsewhere: in how data is captured, in whether it can be tied to a specific part, in whether suppliers see the demand signal, in whether the contract rewards the right outcome. A tool placed in the maintenance department can only work with what reaches the maintenance department. If that is incomplete, the tool inherits the deficiency and obscures it.
There is a further risk: activity that looks like progress. Dashboards appear and predictions are made, while aircraft availability may or may not move. This is the weakness the Inspector General found in a different context: estimates never checked against results.
The alternative is not to wait for perfect data. It is to build the enterprise and the data thread together, with contracts that reward availability, and then to apply AI where it can be tested against outcomes. That is slower to describe and harder to buy. It is also, I believe, the only approach that compounds.
I could be wrong if tool-first deployments, applied to carefully chosen problems, deliver fast gains that the data-first argument underestimates; modest tools might improve data capture in the very act of being used. I could also be wrong about Ariel, if it proves to be a better interface to existing records and not a model of the industrial base, I will say so plainly.
For all the novelty of the technology, the underlying argument is an old one. Capability is not the same as the system that sustains capability. The difference now is that the logistics system is becoming computational. Decisions once made by experienced sergeants and supply officers, based on judgment and local knowledge, will increasingly be made or shaped by software, and the quality of that software’s conclusions will be determined, in the end, by the quality of what we feed it and the quality of the enterprise that acts on its answers.
The Questions That Will Decide the Outcome
The argument comes down to a handful of questions. Whoever answers them well, in the Pentagon, at NAVAIR, at DLA, or in industry, will get value from AI in sustainment. Whoever skips them will buy speed and call it progress.
Is the data fit to reason over? Is it traceable to the serial-numbered part, captured where the work is done, and trusted by the people who use it? If not, what is the plan to fix it before the algorithm is switched on?
Is the enterprise built to act? Is there a contract that rewards aircraft availability and not merely parts delivery, and a data environment that links a change in parts to a change in readiness? Who has the authority to move a part, a repair slot, or a supplier order when the model says to?
Do the two halves connect? When fatigue monitoring shows a component trending toward its limit, how does that signal reach the supply chain, and how quickly? Where does the digital thread hold, and where does it still break?
Who owns the data, and who can see it? Government, prime, suppliers, and depots each hold part of the picture. Can the pieces be joined without one party’s tool becoming another’s lock-in?
How will we know it works? What is the metric, who audits it, and what would count as failure? The Inspector General’s finding on unvalidated savings is the warning: estimates must be checked against results.
Can it travel? Does the combination of PBL, the digital thread, and AI amount to a template that other naval aviation programs can adopt, or does it depend on circumstances particular to one fleet?
And can it survive contact with a distributed fight? A force operating from dispersed sites, against a clock, cannot wait for a perfect network or a clean dataset. Will the sustainment enterprise degrade gracefully when the data does?
These are old questions about old things: contracts, metrics, and the discipline of knowing what you have and where it is. They decide whether an aircraft is available when a Marine commander needs it. The real question facing AI and sustainment is whether we will build the enterprise first, or buy the tool and hope the enterprise follows.
And for a video which highlights the argument, see the following:
AI and the Sustainment Enterprise Storyboard