The thing that kills a maintenance visit is almost never that the work was hard. It's that an open item sat unwatched until it stopped being fixable. A part with a twelve-week lead time is a routine order fourteen weeks out and an impossible one at ten, and the only difference between those two shops is whether someone was watching.
Matt wrote about visits moving through gates: points where work stops until something is ready. My last post was about the layer underneath, knowing the airplane well enough to put its future work on the calendar years before it's urgent. A schedule built years out is where most surprises go to die. But a date on the calendar is a promise, not a finished plan. Between the day a visit gets booked and the day the airplane rolls in, a long list of small things has to become true: the right parts on the shelf, the right person available, the records current, the customer's authorization in hand.
This post is about the machinery that watches that list.
What a gate looks like up close
Take customer authorization, the gate Matt used in his post. Before an owner can say yes, someone at the shop has to put a package together: what was found, the evidence behind it, the recommended action, a price, where the parts stand, and what it does to the schedule. Six items. Walk into any shop and ask why an estimate is stalled, and the answer is one of those six.
Now look at each item the way I do. Every one of them has a person responsible for it, a thing it needs, and a status: done, not done, or stuck behind another item. The price is stuck behind the parts status. The parts status is waiting on a distributor quote. The schedule effect is stuck behind both. None of that is a judgment call. It's a set of facts with a known shape, and facts with a known shape are something software can hold onto and keep current.
Keeping it current is the whole idea. The day the distributor quote lands, the parts status resolves, the price unblocks, the schedule effect unblocks, and the gate re-checks itself. Three items change state and nobody had to notice. Now run that across every gate on every developing visit in the shop, so the day something upstream moves, everything downstream of it moves too.
An engineer calls that a , evaluated continuously. A service manager calls it Tuesday, minus the part where they personally rebuild it from memory at 6:45 every morning.
To be plain about what this is not: it is not "AI plans your shop." It's the shop's own list, watched without fatigue.
The checklist is cheap. The judgment behind it isn't.
Tracking checkboxes is bookkeeping, and bookkeeping doesn't clear gates. Being right does. The value of a check depends entirely on the intelligence behind the individual item, and that's where most of the real work is.
Start with the scope estimate, the input the whole authorization package hangs on. The nominal answer is the manufacturer's inspection checklist, which every shop already has. The useful answer is the one your best estimator carries in their head: on an airplane of this model, this age, this equipment, with these open squawks and this utilization, what does the annual usually turn into? Which findings show up often enough on airplanes like this one that a smart shop prices and sources for them now, instead of discovering them on the table with the owner already gone home? Experienced estimators make that call from memory of the few hundred airplanes they've personally seen. It's exactly the kind of judgment that sharpens as a platform sees more airplanes than any one shop ever will. It's also the same projection that turns a due list into a labor-hours forecast, which is the honest answer to a gap I left open in the last post.
"What's coming due" works the same way. The last post was one long example of how wrong that question can go: a due date depends on rules that appear nowhere in the airplane's records, like whether a life-limited part's clock runs from installation or from manufacture. A gate that says a requirement is or isn't due is only as good as the domain knowledge underneath that determination. The gate is the trigger. The intelligence is knowing what's actually true.
Squawks are the same story from the other direction. Matt's example was an intermittent low-voltage indication after a hot start. The unintelligent version files the squawk and the technician starts from nothing. The useful version recognizes the shape of the complaint from other airplanes that have reported something like it, surfaces the service bulletins and prior findings that turned out to matter, and hands the technician a starting point instead of a blank page. The technician still does the diagnosis. They just don't start from zero, because the platform has seen the pattern before, on airplanes that were never in this shop. A correction one shop makes becomes something every shop starts with. That mechanism deserves its own post, and it will get one.
When a check comes back "not ready"
Starting around six months before a booked date, the gate engine works the list on a schedule. Records not yet received. Hours not updated since March. An AD with a recurring inspection landing before the arrival date, evaluated against the correct basis. A part whose lead time means the order-by date has a name. The checking is cheap and it never gets tired, but the value isn't the tirelessness. It's that the machine is checking the right things for the right reasons, and sorting everything that's open by the date each item stops being fixable.
What happens when something comes back unresolved is a dial, and the shop sets it per gate.
At one end, the system only surfaces. Here is what's open on this visit, in order of urgency, go handle it. That alone is most of the value, because the twelve-week part is only impossible when nobody saw it at week fourteen.
Further along, the system drafts. The quote request, the message to the customer, the schedule note. A person approves before anything goes out.
At the far end, for routine, low-stakes items, it acts under a rule the shop wrote. Reordering the consumable that is always reordered. Sending the scheduling reminder. People hear about the exceptions.
Most of the engineering ahead of us is connection work, and that is by design. A shop already runs on systems that work: the distributors it buys from, the messaging its customers actually answer, the calendar the front office lives in. We are not asking anyone to rip those out. The gates connect to them. A gate that knows a part needs ordering requests the quote from the shop's own distributor. A gate that needs a decision from the customer sends the message through the channel that customer already reads. Every one of those connections is real engineering, with its own authentication and its own data quirks, and building them well is most of the work in front of us. The logic that detects the open item is identical at every setting on the dial. What differs is only whether the last step is a line on a dashboard or an API call.
Some shops will want a person to approve every outbound action until they trust it. Others will hand over the routine immediately and ask to hear about exceptions only. Both are correct. How much of the acting a shop delegates is something it earns its way into at its own pace, not a switch we flip for them.
Where the machine stops
I'll be direct about the limits, because the industry is currently long on AI promises and short on AI accountability.
We are not automating the mechanic's judgment. We're not determining airworthiness, not signing anything, not deciding whether a finding is a discrepancy, and not making the applicability call on a borderline AD. Those decisions belong to certificated people who are accountable for them, and no part of our architecture assumes otherwise.
But stopping at the decision is not the same as being absent from it. An inspector deciding whether a finding is a discrepancy shouldn't also have to be the person who digs out the service history, the prior findings on similar airplanes, and the three record entries that bear on the question. That assembly is exactly what the platform is for: put the relevant evidence in front of the person whose call it is, and let them decide with the full picture instead of the recoverable fraction of it. We can't hold a certificate, so we sign nothing. What we can do is make sure the person who signs is the best-informed signer in the history of that airplane. The call stays with the mechanic; the homework shows up done.
Ordering a part the shop already agreed it needs is not one of those decisions, and the line between the two is worth stating plainly. When a gate places an order under a rule the shop wrote, it isn't exercising judgment. It's running an errand the shop already decided on. The judgment happened earlier, when a qualified person confirmed the part was applicable and the shop set the rule. The line we hold is simple: the software never makes a call that requires a certificate. It only runs the errands that don't.
That is also why every gate action is logged, attributable, and auditable. If a gate placed an order, you can see which gate, under which rule, against which precondition, at what time. An automated action you can't audit is just a faster way to be wrong at scale, and we've already had our one wrong answer for the year.
The same morning, replayed
My last post opened on a component we found by coincidence, already due, that nobody had scheduled. Here is how that morning goes with the scheduler and the gates both running.
Two years earlier, the system reads the line cutters' date of manufacture, applies the six-year interval from the correct basis, and writes a dated requirement onto the calendar with an owner and a shop attached. Not a reminder. A requirement. When the customer books the next annual that falls inside the window, the scheduler snaps the replacement to that visit, so one trip covers both.
Around six months out, the gates pick the visit up. What's the lead time on the line cutter assembly? If it's two months, the order-by date has a name, and depending on how this shop set the dial, that lands as a task in the parts queue or the gate requests the quote itself and, once someone approves it, places the order. Either way the date lives in the system instead of in somebody's memory. Is someone at the shop qualified for the work and available that week? If not, there are six months of runway to move the date, move the person, or see the hiring problem while it's still solvable.
By the time the airplane rolls in, the component is on the shelf, the labor is assigned, and the visit is a scheduled event instead of a discovery. The gates ran between reviews, not instead of them. When the shop's experienced people looked in on the developing visit, the picture was already current and the open items were already on top.
That's the whole ambition, and it's smaller and more concrete than "AI for maintenance." Three questions, stacked. The scheduler answers when the airplane should come in. The gates answer what isn't ready yet for a visit that's coming. And the intelligence underneath both answers the question that used to live only in the head of the most experienced person in the building: what is likely true about this specific airplane that a checklist would never tell you?
Matt made a promise in his post that I want to answer directly: that this adds planning capacity without headcount growing at the same rate as workload. The mechanism has no magic in it. The scarce thing in a shop is not knowledge. It's the uninterrupted attention of the people who have it, and today that attention gets spent assembling packages, chasing records, and re-deriving the state of visits that no system was keeping current. A gate that keeps every developing visit current between reviews gives those hours back, and it brings some of what only the veteran knew to every visit instead of the ones that veteran personally touches. Matt drew the gates. This is us building the machine that clears them.