Nothing.
That is what happened after the best demo I had ever given.
I had walked a maintenance planning team through Trakt for fifty minutes. Component health across the fleet. Remaining useful life on every part we were tracking. Failure probability out to ninety days. Four aircraft flagged critical, twelve flagged warning, and for each one an explanation showing exactly which readings had moved the estimate and how the risk split across wear, fatigue, corrosion, overheating and contamination. Nobody in that room could poke a hole in the math, and a few of them tried.
At the end the planning lead leaned back and asked the only question that mattered.
"So what do I do with this on Monday?"
I said something about exporting it. He nodded politely. I found out later that the answer was nothing. They looked at it for three weeks. They agreed it was accurate. They took screenshots of it and pasted them into a slide for a monthly review. And every single maintenance decision that month got made the exact same way it had been made the month before, in AMOS, by a planner, off a task list that had never heard of us.
We were right about the aircraft and useless to the airline.
That gap between being right and being used is the most expensive thing in this industry, and almost nobody prices it. I want to talk about what actually sits inside it, because I spent a year of engineering finding out, and most of that year went into work that no analyst report has a line item for.
Here is the shape of the problem.
A prediction that terminates in a human eyeball is a screenshot. It has no downstream. It cannot be scheduled, it cannot be costed, it cannot be audited later, and above all it cannot be wrong in any way the system will ever find out about. It renders, someone looks at it, and it evaporates.
Meanwhile the actual operation runs somewhere else entirely. It runs in AMOS or TRAX or Maintenix. It runs in the planner's board, in the stand allocation sheet, in the rebooking screen at the gate. That is where work gets committed and where money moves. If your prediction does not arrive inside those systems, carrying enough structure to become an action, then you have not deployed anything. You have installed a second screen next to the first one and asked a busy person to reconcile them by hand, forever, at their own expense.
SITA's 2025 research says 51% of airlines now use AI to predict delays and disruption, and 83% use AI for operational decisions. Those adoption numbers are enormous. They also sit alongside airline IT spend that has been flat at 3.6% of revenue since 2023, and alongside SITA's own conclusion that where data does not flow freely across systems and partners, investment cannot deliver what it was designed to unlock.
Read those together and a picture forms. A very large number of operators have a prediction. A much smaller number have a handoff. The difference between those two populations is the difference between a pilot that gets renewed and one that quietly dies at the end of its term while everyone says nice things about the accuracy.
I have been on the wrong side of that difference. I built the accuracy first because accuracy is the part that feels like the hard problem. The hard problem was the last hundred feet.
Before I get into the engineering, I want to put two events on the table that every person in this industry has an opinion about, because I think almost everybody has drawn the wrong lesson from them.
December 2022. A winter storm hit, and every US carrier took a beating. Most of them recovered inside a few days. Southwest did not. It canceled close to seventeen thousand flights over ten days, stranded more than two million passengers, and took the largest consumer protection penalty the DOT has ever issued at $140 million. The airline put its own cost at more than $1.1 billion in refunds, reimbursements, extra operating expense and lost sales.
Here is the part I want you to sit with. The crew scheduling system became overloaded and could not keep up. Southwest's own pilot union had warned management about the vulnerability beforehand.
Nobody at Southwest lacked a prediction. They knew a storm was coming. They knew which crews were where. They knew, in aggregate, exactly how bad it was. What broke was the machinery that turns knowledge into an assignment, at the volume the day demanded.
July 2024. A faulty CrowdStrike update crashed millions of Windows machines worldwide. Every industry got hit. Airlines got hit. And again, most of them recovered inside two days while Delta canceled roughly seven thousand flights over five, affected 1.3 million passengers, and took a half billion dollar hit in under a week.
Why Delta specifically? The company's own explanation was that one of its crew tracking tools could not process the volume of changes the shutdown triggered. Forty thousand servers had to be reset by hand.
Same shape. The information was recoverable. The operation was not, because the component that had to convert information into a crew assignment could not carry the load.
I would add a third, less obviously technological. When a substation fire shut Heathrow for the day in March 2025, around 1,350 flights went with it, and the airport reopened within eighteen hours. The disruption still ran for days afterward, because aircraft and crews were in the wrong places and the recalculation had to happen carrier by carrier, network by network. The physical problem was fixed by lunchtime the next day. The repositioning problem was not.
Three events, hundreds of millions of dollars each, and in every case the failure sat at the seam between knowing and doing.
That seam is where I want to spend the rest of this piece, because if a billion dollar carrier can lose a quarter on it, a vendor shipping predictions into it should probably take it seriously.
Nobody funds the last hundred feet. It does not demo well, it produces no chart, and it is almost entirely made of unglamorous questions that only surface when a real operation tries to use your output at real volume.
Here is what we had to build before a prediction could survive contact with a planner.
It has to become a work order without a human retyping it. Trakt has an endpoint whose entire job is that conversion. You hand it a component, and optionally a target date and a priority, and it returns a real work order with a real number in the format
It has to work in batches, because operations are not one component at a time. A planner reviewing a week does not approve one prediction. They approve two hundred. So the bulk conversion accepts up to two hundred rows in a single request, applies defaults to every row that does not set its own, and treats each row independently, so one bad row does not take the batch down with it. The response tells you exactly which rows landed and which did not, with a reason attached. There is a
We charge that as one bulk operation regardless of how many rows it carries. That was a deliberate decision. The moment volume becomes expensive, volume becomes the reason to do less, and doing less is how a deployment dies.
It has to reach the customer's systems without them polling us into the ground. So there is a change feed that returns only what has moved since the last call, with a cursor that resumes exactly where a consumer stopped. A client that misses a page and restarts from its stored cursor converges on its own. That feed is available on every plan including read only, and it does not spend the interactive allowance, so keeping a live mirror of fleet state costs nothing from the budget the actual users depend on.
Or it has to arrive without being asked for. Register an endpoint and Trakt posts to it the moment a component changes health band in either direction, the moment something enters critical, the moment a due date is crossed. Signed with the customer's own secret. Fired on the transition rather than on every scan, so a steady fleet sends silence. An endpoint that keeps failing gets paused automatically, because a decommissioned URL should never turn into a backlog.
And it has to be defensible when someone asks why. Every prediction can produce its own reasoning: which readings moved it, in which direction, how much of the signal each one carried, and how the risk divides across failure modes. Fifty of those at once for anyone building a reliability study. That endpoint is on every plan too, including the cheapest one, because an explanation you have to upgrade to buy is not something you can build a safety argument on.
None of that is intelligence. All of it is plumbing. And the plumbing is where the value actually got created, because until it existed, everything upstream of it was a screenshot.
I would also point out, gently, that the Southwest and Delta failures were failures of exactly this layer. Not of judgment. Not of data. Of throughput at the seam.
Now the part I did not see coming, and the part I would build first if I were starting again.
When you build the handoff properly, you accidentally build a microscope.
Think about what a real handoff records. The model said this component needed attention in this window. The planner then did something. Maybe they accepted it. Maybe they moved it two weeks out because a C check was already scheduled and bundling was cheaper. Maybe they ignored it entirely because they have serviced that part for eleven years and they know something the model does not. And then, later, reality settled the argument.
Three facts, tied to one movement. What was predicted. What was decided. What happened.
Almost nobody in enterprise AI holds all three. Vendors hold the first. Customers hold the third, scattered across systems that were never designed to talk to each other. The middle one, the decision, usually exists nowhere at all, because the moment a human overrules a model is exactly the moment nobody writes anything down.
In SANS.AI, that middle fact is a first class object. The turnaround allocation loop is literally three stages: predict, decide, verify. Each movement is scored for the resources it will need. The planner accepts the prediction or allocates by hand, and that choice is recorded. Then predictions are compared against the allocations that actually happened. Those recorded decisions become training data, which means the models learn how that specific operation behaves rather than an industry average, and they keep pace as the stand mix and the fleet and the staffing change underneath them.
The same shape shows up in the safety module, and there it is even sharper. Acknowledging an alert is one call, and it carries a disposition. Was it actioned, referred, stood down, judged a duplicate, or judged a false positive? Two of those leave the alert open, because the work is still open. The rest resolve it.
I want to underline why that field exists, because it took an argument internally to get it in.
An alert nobody acted on and an alert correctly stood down look identical in the record without it. Identical. And the difference between those two is the entire question of whether the module is helping anyone. Strip out the disposition and you can run that system for two years and have no idea whether you built a safety tool or an expensive source of noise.
Trakt does the same thing from the other direction. When an optimizer schedules maintenance slots, it can post those slots back, and each one gets scored against the failure window Trakt originally issued. We hold that window as a distribution rather than a date, with a rectangular form covering p10 to p90 for binary coverage and a triangular form around the median for graded scoring, and the spread is adjusted by the model's own confidence. So the feedback is not a thumbs up. It is a coverage rate and a proximity score, persisted, with retraining queued automatically once enough of them accumulate.
And S-System closes the loop on the commercial side. Every ancillary offer is recorded with the price shown, the reasons behind that price, and whether it converted.
Once you have the handoff, the loop is nearly free. Without the handoff, the loop is impossible, because there is no moment at which anything gets committed.
That is the argument I would make to any founder building prediction into an operation. The handoff is not the last mile of your product. It is the sensor.
I know the objection, because I have taken it in the face across a table.
It goes like this. Maintenance decisions carry regulatory sign off. A licensed engineer is legally accountable for airworthiness, and no model gets to schedule work over their head. Air traffic control is a controlled function and your software has no business anywhere near it. Turnaround allocation involves union agreements, rest rules and contracts with ground handlers. You cannot just wire a prediction into an action.
Every word of that is correct, and we say so in our own documentation in language that some people have told me is commercially unwise. SANS.AI is supplementary safety monitoring. It performs no air traffic control function. It is not certified to a software assurance level under ED-109A or DO-278A, that work is a multi year effort, and it is not finished. Separation assurance stays with the ANSP. We would rather tell a customer where we are than let a procurement question find it.
But notice that the objection is about autonomy, and I am arguing for handoff. Those are different things.
A handoff means the prediction arrives in the system where the decision gets made, in a structure the decision maker can act on, with its reasoning attached, and with the resulting choice recorded. The engineer still signs. The planner still allocates. The controller still controls. What changes is that the human decision now happens with the model's estimate in front of it instead of in a different application on a different screen, and that the decision itself leaves a trace.
The
Autonomy is a licensing and assurance question, and ours will take years. Handoff is an engineering question, and it is available right now.
We built three products for three different buyers, and I did not notice until this year that we had built the same thing three times.
Trakt predicts a component failure, converts it into a work order, and scores the schedule that came back against the window it issued.
SANS.AI predicts what a turnaround will need, records what the planner decided, and verifies both against what actually happened at the stand.
S-System predicts a disruption, suggests the rebooking, prices the offer with its reasons attached, and records whether the passenger took it.
Predict. Commit. Record. Compare.
Three codebases, three buyers who do not know each other, one shape. That was not a strategy. It was three teams independently discovering that a prediction with no commit step is inert, and that a commit step with no comparison step teaches you nothing.
There is a corollary that I think matters more than the pattern itself. Because each of those systems commits into the operation, each one knows something the others should have. A component pulled forward changes an aircraft's availability. Changed availability changes schedule risk. Schedule risk changes what a station has to absorb on the day. What a station absorbs changes how many passengers sit in a terminal past the threshold where a delay stops being an inconvenience and becomes a statutory liability of six hundred euros a head under EU261, or nothing at all on a US domestic sector, depending entirely on the route and the operating carrier.
That is one causal chain running from a vibrating actuator to a legal exposure. Every hop in it is a handoff. Take any single hop out and the chain becomes four screenshots.
I wrote a piece a while back arguing that predictive maintenance sells the removal of waiting, and I still believe that. This is the sentence underneath it.
Advance warning has no value on its own. Two to thirteen weeks of notice about a component is worth exactly zero until somebody does something differently because of it. The part gets ordered before the aircraft enters the bay. The task gets bundled into work already on the schedule. The slot gets taken when it suits the operation instead of when a failure forces it. Unplanned removals run thirty to fifty percent more expensive than planned ones, and that premium is not paid for the wrench work. It is paid for the emergency around the wrench work.
Every one of those savings is realized at a handoff. Not one of them is realized at the prediction.
Which brings me to the objection I owe you before you raise it yourself, because it is the honest one.
The defining maintenance event of this decade is the geared turbofan powder metal problem. Contaminated material in high pressure turbine and compressor discs manufactured between 2015 and 2021, hundreds of engines pulled for inspection, and a grounding crisis that has run for years. Wizz Air had around forty aircraft on the ground at the end of 2024 and thirty three a year later, close to a fifth of its A320neo family fleet, with full recovery now pushed toward 2027. Spirit and IndiGo took comparable damage on a comparable scale.
No prediction system on earth was going to catch a materials defect introduced at the foundry. I am not going to pretend otherwise, and anybody in my industry who implies they would have is selling you something.
But look at what the crisis actually became once the defect was known. It became a queueing problem. Which engine comes off which wing, in which order, into which shop slot, with which spare, against which route network. Every one of those is a scheduling decision made at volume under constraint, and every one of them is a handoff. The defect was a manufacturing failure. The four years of grounded aircraft is substantially a sequencing failure, and sequencing is the thing prediction is actually good for.
Which is why I think the industry undersells itself so badly on sizing. Analysts put aircraft predictive maintenance at somewhere around seven billion dollars. Oliver Wyman puts global MRO demand at $136 billion and rising toward $193 billion by the end of the decade, and IATA's own maintenance cost work has MRO climbing to 11.5% of airline expenses. Add the roughly $30 billion a year the industry burns on delays. Boeing's long standing estimate is that a one to two hour AOG runs ten to twenty thousand dollars and can reach a hundred and fifty thousand an hour on the wrong aircraft and the wrong route.
The seven billion is what people spend on the screen. The rest is what the handoff moves.
I lost three weeks with that planning team, and I deserved to.
I had confused a correct answer with a delivered one. The models were fine. The failure was that I had built something that ended where the operation began, and then acted surprised when nothing changed. Every hour I subsequently spent on cursors, idempotency, signed deliveries, per row error reporting and a dry run flag felt at the time like it was stealing hours from the interesting work.
It was the interesting work. It was the only part of the system that could touch a decision.
And I would say the same thing to the industry, with more confidence than I had a year ago. Southwest did not lose a billion dollars because it failed to forecast a storm. Delta did not lose half a billion because it could not tell which crews were legal. Both of them lost it at the seam, in the software that had to turn a known situation into thousands of committed assignments, quickly, under load. That layer got underfunded for a decade because it never looked like innovation.
So here is what I would tell anyone building AI into an operation, in any industry where equipment reliability or asset availability matters. Before you tune another model, go and find the exact screen where the decision your prediction is meant to change actually gets made. Find out who is sitting in front of it, what system it lives in, and what would have to be true for your output to arrive inside it already shaped like an action.
If your answer involves the phrase "and then they export it," you have built a screenshot.
Stop measuring your accuracy. Go find your handoff.
V is the CEO of Kquika, where he builds Trakt System, SANS.AI and S-System for airlines, airports and government agencies.
That is what happened after the best demo I had ever given.
I had walked a maintenance planning team through Trakt for fifty minutes. Component health across the fleet. Remaining useful life on every part we were tracking. Failure probability out to ninety days. Four aircraft flagged critical, twelve flagged warning, and for each one an explanation showing exactly which readings had moved the estimate and how the risk split across wear, fatigue, corrosion, overheating and contamination. Nobody in that room could poke a hole in the math, and a few of them tried.
At the end the planning lead leaned back and asked the only question that mattered.
"So what do I do with this on Monday?"
I said something about exporting it. He nodded politely. I found out later that the answer was nothing. They looked at it for three weeks. They agreed it was accurate. They took screenshots of it and pasted them into a slide for a monthly review. And every single maintenance decision that month got made the exact same way it had been made the month before, in AMOS, by a planner, off a task list that had never heard of us.
We were right about the aircraft and useless to the airline.
That gap between being right and being used is the most expensive thing in this industry, and almost nobody prices it. I want to talk about what actually sits inside it, because I spent a year of engineering finding out, and most of that year went into work that no analyst report has a line item for.
Part I: The Screenshot
Here is the shape of the problem.
A prediction that terminates in a human eyeball is a screenshot. It has no downstream. It cannot be scheduled, it cannot be costed, it cannot be audited later, and above all it cannot be wrong in any way the system will ever find out about. It renders, someone looks at it, and it evaporates.
Meanwhile the actual operation runs somewhere else entirely. It runs in AMOS or TRAX or Maintenix. It runs in the planner's board, in the stand allocation sheet, in the rebooking screen at the gate. That is where work gets committed and where money moves. If your prediction does not arrive inside those systems, carrying enough structure to become an action, then you have not deployed anything. You have installed a second screen next to the first one and asked a busy person to reconcile them by hand, forever, at their own expense.
SITA's 2025 research says 51% of airlines now use AI to predict delays and disruption, and 83% use AI for operational decisions. Those adoption numbers are enormous. They also sit alongside airline IT spend that has been flat at 3.6% of revenue since 2023, and alongside SITA's own conclusion that where data does not flow freely across systems and partners, investment cannot deliver what it was designed to unlock.
Read those together and a picture forms. A very large number of operators have a prediction. A much smaller number have a handoff. The difference between those two populations is the difference between a pilot that gets renewed and one that quietly dies at the end of its term while everyone says nice things about the accuracy.
I have been on the wrong side of that difference. I built the accuracy first because accuracy is the part that feels like the hard problem. The hard problem was the last hundred feet.
Part II: The Failures You Already Know By Name
Before I get into the engineering, I want to put two events on the table that every person in this industry has an opinion about, because I think almost everybody has drawn the wrong lesson from them.
December 2022. A winter storm hit, and every US carrier took a beating. Most of them recovered inside a few days. Southwest did not. It canceled close to seventeen thousand flights over ten days, stranded more than two million passengers, and took the largest consumer protection penalty the DOT has ever issued at $140 million. The airline put its own cost at more than $1.1 billion in refunds, reimbursements, extra operating expense and lost sales.
Here is the part I want you to sit with. The crew scheduling system became overloaded and could not keep up. Southwest's own pilot union had warned management about the vulnerability beforehand.
Nobody at Southwest lacked a prediction. They knew a storm was coming. They knew which crews were where. They knew, in aggregate, exactly how bad it was. What broke was the machinery that turns knowledge into an assignment, at the volume the day demanded.
July 2024. A faulty CrowdStrike update crashed millions of Windows machines worldwide. Every industry got hit. Airlines got hit. And again, most of them recovered inside two days while Delta canceled roughly seven thousand flights over five, affected 1.3 million passengers, and took a half billion dollar hit in under a week.
Why Delta specifically? The company's own explanation was that one of its crew tracking tools could not process the volume of changes the shutdown triggered. Forty thousand servers had to be reset by hand.
Same shape. The information was recoverable. The operation was not, because the component that had to convert information into a crew assignment could not carry the load.
I would add a third, less obviously technological. When a substation fire shut Heathrow for the day in March 2025, around 1,350 flights went with it, and the airport reopened within eighteen hours. The disruption still ran for days afterward, because aircraft and crews were in the wrong places and the recalculation had to happen carrier by carrier, network by network. The physical problem was fixed by lunchtime the next day. The repositioning problem was not.
Three events, hundreds of millions of dollars each, and in every case the failure sat at the seam between knowing and doing.
That seam is where I want to spend the rest of this piece, because if a billion dollar carrier can lose a quarter on it, a vendor shipping predictions into it should probably take it seriously.
Part III: The Last Hundred Feet
Nobody funds the last hundred feet. It does not demo well, it produces no chart, and it is almost entirely made of unglamorous questions that only surface when a real operation tries to use your output at real volume.
Here is what we had to build before a prediction could survive contact with a planner.
It has to become a work order without a human retyping it. Trakt has an endpoint whose entire job is that conversion. You hand it a component, and optionally a target date and a priority, and it returns a real work order with a real number in the format
WO-PRED-XXXXXX-TIMESTAMP. If you leave out the work type or the duration, it infers them from the component's own signals rather than refusing to move. That endpoint is boring. It is also the only reason any of the modeling upstream of it has ever changed an outcome.
It has to work in batches, because operations are not one component at a time. A planner reviewing a week does not approve one prediction. They approve two hundred. So the bulk conversion accepts up to two hundred rows in a single request, applies defaults to every row that does not set its own, and treats each row independently, so one bad row does not take the batch down with it. The response tells you exactly which rows landed and which did not, with a reason attached. There is a
dry_run flag that validates and previews the whole batch without writing anything, because the first thing a cautious planner wants is to see what would happen before it happens.
We charge that as one bulk operation regardless of how many rows it carries. That was a deliberate decision. The moment volume becomes expensive, volume becomes the reason to do less, and doing less is how a deployment dies.
It has to reach the customer's systems without them polling us into the ground. So there is a change feed that returns only what has moved since the last call, with a cursor that resumes exactly where a consumer stopped. A client that misses a page and restarts from its stored cursor converges on its own. That feed is available on every plan including read only, and it does not spend the interactive allowance, so keeping a live mirror of fleet state costs nothing from the budget the actual users depend on.
Or it has to arrive without being asked for. Register an endpoint and Trakt posts to it the moment a component changes health band in either direction, the moment something enters critical, the moment a due date is crossed. Signed with the customer's own secret. Fired on the transition rather than on every scan, so a steady fleet sends silence. An endpoint that keeps failing gets paused automatically, because a decommissioned URL should never turn into a backlog.
And it has to be defensible when someone asks why. Every prediction can produce its own reasoning: which readings moved it, in which direction, how much of the signal each one carried, and how the risk divides across failure modes. Fifty of those at once for anyone building a reliability study. That endpoint is on every plan too, including the cheapest one, because an explanation you have to upgrade to buy is not something you can build a safety argument on.
None of that is intelligence. All of it is plumbing. And the plumbing is where the value actually got created, because until it existed, everything upstream of it was a screenshot.
I would also point out, gently, that the Southwest and Delta failures were failures of exactly this layer. Not of judgment. Not of data. Of throughput at the seam.
Part IV: The Gap Between the Prediction and the Decision
Now the part I did not see coming, and the part I would build first if I were starting again.
When you build the handoff properly, you accidentally build a microscope.
Think about what a real handoff records. The model said this component needed attention in this window. The planner then did something. Maybe they accepted it. Maybe they moved it two weeks out because a C check was already scheduled and bundling was cheaper. Maybe they ignored it entirely because they have serviced that part for eleven years and they know something the model does not. And then, later, reality settled the argument.
Three facts, tied to one movement. What was predicted. What was decided. What happened.
Almost nobody in enterprise AI holds all three. Vendors hold the first. Customers hold the third, scattered across systems that were never designed to talk to each other. The middle one, the decision, usually exists nowhere at all, because the moment a human overrules a model is exactly the moment nobody writes anything down.
In SANS.AI, that middle fact is a first class object. The turnaround allocation loop is literally three stages: predict, decide, verify. Each movement is scored for the resources it will need. The planner accepts the prediction or allocates by hand, and that choice is recorded. Then predictions are compared against the allocations that actually happened. Those recorded decisions become training data, which means the models learn how that specific operation behaves rather than an industry average, and they keep pace as the stand mix and the fleet and the staffing change underneath them.
The same shape shows up in the safety module, and there it is even sharper. Acknowledging an alert is one call, and it carries a disposition. Was it actioned, referred, stood down, judged a duplicate, or judged a false positive? Two of those leave the alert open, because the work is still open. The rest resolve it.
I want to underline why that field exists, because it took an argument internally to get it in.
An alert nobody acted on and an alert correctly stood down look identical in the record without it. Identical. And the difference between those two is the entire question of whether the module is helping anyone. Strip out the disposition and you can run that system for two years and have no idea whether you built a safety tool or an expensive source of noise.
Trakt does the same thing from the other direction. When an optimizer schedules maintenance slots, it can post those slots back, and each one gets scored against the failure window Trakt originally issued. We hold that window as a distribution rather than a date, with a rectangular form covering p10 to p90 for binary coverage and a triangular form around the median for graded scoring, and the spread is adjusted by the model's own confidence. So the feedback is not a thumbs up. It is a coverage rate and a proximity score, persisted, with retraining queued automatically once enough of them accumulate.
And S-System closes the loop on the commercial side. Every ancillary offer is recorded with the price shown, the reasons behind that price, and whether it converted.
Once you have the handoff, the loop is nearly free. Without the handoff, the loop is impossible, because there is no moment at which anything gets committed.
That is the argument I would make to any founder building prediction into an operation. The handoff is not the last mile of your product. It is the sensor.
Part V: The Objection
I know the objection, because I have taken it in the face across a table.
It goes like this. Maintenance decisions carry regulatory sign off. A licensed engineer is legally accountable for airworthiness, and no model gets to schedule work over their head. Air traffic control is a controlled function and your software has no business anywhere near it. Turnaround allocation involves union agreements, rest rules and contracts with ground handlers. You cannot just wire a prediction into an action.
Every word of that is correct, and we say so in our own documentation in language that some people have told me is commercially unwise. SANS.AI is supplementary safety monitoring. It performs no air traffic control function. It is not certified to a software assurance level under ED-109A or DO-278A, that work is a multi year effort, and it is not finished. Separation assurance stays with the ANSP. We would rather tell a customer where we are than let a procurement question find it.
But notice that the objection is about autonomy, and I am arguing for handoff. Those are different things.
A handoff means the prediction arrives in the system where the decision gets made, in a structure the decision maker can act on, with its reasoning attached, and with the resulting choice recorded. The engineer still signs. The planner still allocates. The controller still controls. What changes is that the human decision now happens with the model's estimate in front of it instead of in a different application on a different screen, and that the decision itself leaves a trace.
The
dry_run flag exists for exactly this reason. So does the fact that a bulk conversion approves rows a human selected rather than everything the model flagged. Approval is a human act in our system by design, and I would build it that way even if regulation vanished tomorrow, because a system that acts without approval never records a disagreement, and the disagreements are where the learning lives.
Autonomy is a licensing and assurance question, and ours will take years. Handoff is an engineering question, and it is available right now.
Part VI: The Same Shape, Three Times
We built three products for three different buyers, and I did not notice until this year that we had built the same thing three times.
Trakt predicts a component failure, converts it into a work order, and scores the schedule that came back against the window it issued.
SANS.AI predicts what a turnaround will need, records what the planner decided, and verifies both against what actually happened at the stand.
S-System predicts a disruption, suggests the rebooking, prices the offer with its reasons attached, and records whether the passenger took it.
Predict. Commit. Record. Compare.
Three codebases, three buyers who do not know each other, one shape. That was not a strategy. It was three teams independently discovering that a prediction with no commit step is inert, and that a commit step with no comparison step teaches you nothing.
There is a corollary that I think matters more than the pattern itself. Because each of those systems commits into the operation, each one knows something the others should have. A component pulled forward changes an aircraft's availability. Changed availability changes schedule risk. Schedule risk changes what a station has to absorb on the day. What a station absorbs changes how many passengers sit in a terminal past the threshold where a delay stops being an inconvenience and becomes a statutory liability of six hundred euros a head under EU261, or nothing at all on a US domestic sector, depending entirely on the route and the operating carrier.
That is one causal chain running from a vibrating actuator to a legal exposure. Every hop in it is a handoff. Take any single hop out and the chain becomes four screenshots.
Part VII: What Prediction Is Actually Selling
I wrote a piece a while back arguing that predictive maintenance sells the removal of waiting, and I still believe that. This is the sentence underneath it.
Advance warning has no value on its own. Two to thirteen weeks of notice about a component is worth exactly zero until somebody does something differently because of it. The part gets ordered before the aircraft enters the bay. The task gets bundled into work already on the schedule. The slot gets taken when it suits the operation instead of when a failure forces it. Unplanned removals run thirty to fifty percent more expensive than planned ones, and that premium is not paid for the wrench work. It is paid for the emergency around the wrench work.
Every one of those savings is realized at a handoff. Not one of them is realized at the prediction.
Which brings me to the objection I owe you before you raise it yourself, because it is the honest one.
The defining maintenance event of this decade is the geared turbofan powder metal problem. Contaminated material in high pressure turbine and compressor discs manufactured between 2015 and 2021, hundreds of engines pulled for inspection, and a grounding crisis that has run for years. Wizz Air had around forty aircraft on the ground at the end of 2024 and thirty three a year later, close to a fifth of its A320neo family fleet, with full recovery now pushed toward 2027. Spirit and IndiGo took comparable damage on a comparable scale.
No prediction system on earth was going to catch a materials defect introduced at the foundry. I am not going to pretend otherwise, and anybody in my industry who implies they would have is selling you something.
But look at what the crisis actually became once the defect was known. It became a queueing problem. Which engine comes off which wing, in which order, into which shop slot, with which spare, against which route network. Every one of those is a scheduling decision made at volume under constraint, and every one of them is a handoff. The defect was a manufacturing failure. The four years of grounded aircraft is substantially a sequencing failure, and sequencing is the thing prediction is actually good for.
Which is why I think the industry undersells itself so badly on sizing. Analysts put aircraft predictive maintenance at somewhere around seven billion dollars. Oliver Wyman puts global MRO demand at $136 billion and rising toward $193 billion by the end of the decade, and IATA's own maintenance cost work has MRO climbing to 11.5% of airline expenses. Add the roughly $30 billion a year the industry burns on delays. Boeing's long standing estimate is that a one to two hour AOG runs ten to twenty thousand dollars and can reach a hundred and fifty thousand an hour on the wrong aircraft and the wrong route.
The seven billion is what people spend on the screen. The rest is what the handoff moves.
What I Actually Believe
I lost three weeks with that planning team, and I deserved to.
I had confused a correct answer with a delivered one. The models were fine. The failure was that I had built something that ended where the operation began, and then acted surprised when nothing changed. Every hour I subsequently spent on cursors, idempotency, signed deliveries, per row error reporting and a dry run flag felt at the time like it was stealing hours from the interesting work.
It was the interesting work. It was the only part of the system that could touch a decision.
And I would say the same thing to the industry, with more confidence than I had a year ago. Southwest did not lose a billion dollars because it failed to forecast a storm. Delta did not lose half a billion because it could not tell which crews were legal. Both of them lost it at the seam, in the software that had to turn a known situation into thousands of committed assignments, quickly, under load. That layer got underfunded for a decade because it never looked like innovation.
So here is what I would tell anyone building AI into an operation, in any industry where equipment reliability or asset availability matters. Before you tune another model, go and find the exact screen where the decision your prediction is meant to change actually gets made. Find out who is sitting in front of it, what system it lives in, and what would have to be true for your output to arrive inside it already shaped like an action.
If your answer involves the phrase "and then they export it," you have built a screenshot.
Stop measuring your accuracy. Go find your handoff.
V is the CEO of Kquika, where he builds Trakt System, SANS.AI and S-System for airlines, airports and government agencies.
Related Posts
