Knowing the Airplane Before It Arrives

That's the post, more or less. Almost everything that determines whether a maintenance visit goes smoothly is knowable months before the airplane lands. What's coming due. What the last shop found and deferred. Which parts the visit will likely need that are sitting on a twelve-week lead time. Roughly how many technician hours the work will take, and whether the people who can do it are already committed that week. None of it requires the aircraft to be in the hangar. It just has to be assembled, and then it has to be reasoned about correctly, and finally somebody or something has to keep watching it.

I'd recognize the underlying problem from my last job. At FlightAware, one of the more interesting things we built was a set of machine learning models that predicted flight arrival times. The naive framing is that you're predicting the future, which sounds hard and a little magical. The real work was almost entirely upstream of the model: assembling an accurate, current, and complete picture of the present (where the aircraft is, what it is, what the weather is doing, what happened the last three hundred times this route was flown) and doing it continuously. Once you had that, the prediction was comparatively straightforward. Get the present wrong and the model produces confident nonsense.

Maintenance has the same shape. The airplane's future is mostly a function of how well you know its present, and in general aviation we know its present very poorly.

The records problem comes first

An airplane's history is a stack of paper. Handwritten entries, typed entries, stickers, yellow tags, entries that reference a work order nobody kept, entries in three different hands on the same page, and the occasional coffee ring. That stack is the authoritative record of the aircraft, and it is not queryable by anything except a human being with an afternoon to spare.

Our first product is the thing that fixes that. It's a multi-stage pipeline that takes scanned records and produces structured entries: orient the page, classify what kind of document it is, extract the content, run a separate quality-assurance pass over the extraction, and route anything uncertain to a human reviewer before it's committed. We use different models at different stages: a fast, cheap model for classification, a stronger one for extraction, and a different vendor's model as a fallback so that a bad day at one provider isn't a bad day for our customers. That last part is less exciting than it sounds and has saved us more than once.

The rule that governs this whole pipeline, and the one I'd defend hardest, is that extraction transcribes and does not interpret. If the entry says "comp ck 74/80 #3," the pipeline records that the entry says "comp ck 74/80 #3." It does not decide that this is a compression check on cylinder three, it does not normalize the units, and it does not helpfully fill in the cylinder that the mechanic left out. Every bit of reasoning happens downstream, in a system that knows it's reasoning and can be asked to explain itself.

This sounds like a small architectural preference. It isn't. The moment you let the transcription layer make inferences, you lose the ability to answer the first of the two questions that matter in a compliance-adjacent product: where did this come from? We want every assertion the platform makes to trace back to a specific line on a specific page image that a person can pull up and look at. That's only possible if the transcription is faithful, verbatim, and boring.

The second question is why is that the answer?, and the line cutters are what happens when you can answer the first and not the second. I'll come back to it.

The corollary is that we never silently drop what we transcribed. If a value doesn't fit our data model, that's our problem, and we flag it; we don't quietly null it out and move on. That has cost us a fair amount of engineering time, and it's non-negotiable.

Transcription is not understanding

Once the records are structured, the interpretation happens in a separate layer that builds and maintains a digital twin of the aircraft: the airframe, the engine, the propeller, the avionics, the life-limited components, the parachute system, and the events that changed any of them over the airplane's life. It's event-sourced, which is a fancy way of saying we keep the history rather than just the current state, so we can always show our work.

Here's a concrete example of why that layer needs to be separate and needs to be smart. Say you want to know engine time since overhaul. There's usually a number written in the logbook, and it's often right. But it's a snapshot from whenever someone last wrote it down, and it can be wrong or stale or copied forward from a prior entry. The more defensible answer is derived: take the reconciled airframe meter and project from the airframe hours at the last engine event. The stated number in the book becomes a cross-check (a signal that something's off when it disagrees) rather than the source of truth.

There's a Cirrus-specific wrinkle here that anyone who's worked on these airplanes will recognize. Cirrus tracks maintenance on flight hours, not tach. But plenty of shop software only has a field labeled "tach," so the flight hours get entered there, and now the record says something different from what the shop meant. We handle that by resolving the meter in a defined order of preference rather than trusting the label on the field. That's the kind of thing you only get right by talking to shops, and it's the kind of thing that quietly poisons every downstream calculation if you get it wrong.

We do the same kind of work on applicability. An AD or a service bulletin is only relevant to a specific set of aircraft, and the effectivity is usually expressed in serial ranges, dates of manufacture, installed equipment, etc. That mostly works, until you hit an airplane whose serial number falls inside a range but which left the factory with a different engine than the rest of that range. The clean data model can't express that. So we've built in the ability to override at the point of evaluation, documented the cases where we know the general rule is wrong, and moved on. I'd rather ship something with a known and annotated edge case than pretend the model is complete.

Which brings me back to the line cutters. Every life-limited component carries an interval, and every interval runs from something: install date, date of manufacture, hours in service, cycles, overhaul date. The interval is usually easy to find. The basis is the part that gets assumed, and install date is the assumption that's right often enough to be dangerous. It was right for nearly everything else in that airplane's records, which is exactly why nobody caught it.

The fix in the data model was small. The lesson isn't. Any system that derives compliance dates is carrying a large set of rules that don't appear anywhere in the aircraft's records, and the failure mode is quiet: no error, no missing field, no low confidence score, just a date that looks entirely reasonable and is nine months late. Treating the basis as a first-class piece of data with its own source and its own review history is the only version of this I'm comfortable with.

Projecting forward to the arrival date

Knowing the aircraft's current state gets you a due list as of today. A shop planning a visit ninety days out needs the due list as of the arrival date, which means projecting utilization forward.

Some of that is simple arithmetic over historical flight hours. Some of it is the owner telling you they're flying to Oshkosh in July. And increasingly, some of it comes from telemetry: engine data downloads, oil analysis reports, and the other digital exhaust a modern piston airplane produces. We've been working on ingesting oil analysis reports from the major labs and normalizing them into a common shape, which is more annoying than you'd think, in part because "below detection limit" means something different from zero and most systems throw that distinction away.

Where we think this ends up is proactive rather than predictive. I'm skeptical of anything that claims to tell you a cylinder will fail in forty hours. What I do believe in is trend detection: this parameter has moved outside its normal band for this engine in this operating regime, and here's the evidence, so a human should take a look. That's a much more honest use of the data, and it's more useful, because it lands in the shop's queue as a question rather than a verdict.

The scheduler is the part that would have caught this

The order we're building in matters, and it isn't the order I'd have guessed a year ago.

The records and evaluation work is finishing now. Extraction, the digital twin, and the AD, service bulletin, and status evaluation that turns a pile of records into a live due list. That's the foundation, and it's nearly done.

The next thing we build is a scheduling engine. It takes the due list for every aircraft on a shop's book, sets it against what the shop actually has (hangar space, technicians, the specific ratings and authorizations a given job requires), works out when each airplane should come in, and then does the thing shops almost never have time to do: it reaches out to the customer, a year or more ahead, and asks them to reserve the slot. How much of that outreach happens automatically and how much waits for a human is a shop configuration, not a decision we should be making on their behalf.

That tier runs on a horizon of a year to several years, and it's the tier that would have caught this morning's problem. A dated requirement is either on somebody's calendar or it isn't. What I ran into wasn't a hard problem. It was a requirement that had never been on anyone's calendar at all, and no amount of being good at the visit helps with a visit nobody knew to schedule.

The scheduler's second job is flattening demand. Shops rarely run out of capacity in aggregate; they run out in bursts. Three annuals land the same week, or four aircraft need the same inspector on the same two days, or a month of long-lead parts all needed ordering inside the same ten-day window that nobody noticed until it closed. Once you can project scope for every aircraft on the book, those collisions are visible while there's still room to move something. Moving an arrival by a week when it's a year out costs an email. Moving it when it's four days out costs a customer.

One honest gap, because I'd rather name it than imply it's solved. Projecting scope gets you demand. Turning demand into labor hours needs historical actuals across comparable visits, which is a data asset you accumulate rather than derive. We're accumulating it now.

What "done" would look like

Records first, then a model of the aircraft, then a schedule built years out from that model. We're a small team and a fair amount of that is still ahead of us. But the direction is fixed, and there's a way to check our work that I'd rather you use than take my word for.

Pick any statement the platform makes about your airplane. Any due date, any component time, any compliance status. Click it. You should land on the scanned page it came from, in someone's handwriting, with the entry it was derived from. We built that first, and it works today.

The second half is the half this morning taught us we were missing. Ask why that's the answer, and today you get the interval but not the reasoning underneath it. You don't get told what the interval runs from, which document establishes it, or when a human last checked that basis against the source. The number looked right, and there was no way to interrogate why. That's precisely how a date ends up nine months off with nothing flagging it. So the basis is becoming first-class data with its own source and its own review history, for the same reason the transcription is faithful and the twin shows its work: an answer you can't take apart is an answer you can't check, and this is a domain where every answer has to be checkable.

We could have passed the first half of that test this morning and we'd still have been nine months wrong. The line cutters get replaced this month. The rule in our system is fixed, and every other aircraft on the platform carrying that component was re-evaluated the same afternoon. That last part is the only reason I'm comfortable writing this down: a mistake one shop learns from is just a mistake, and a mistake every shop on the platform inherits the fix for is worth something.

A schedule built two years out is where the surprises go to die. But a scheduled date is a promise, not a plan, and keeping it means resolving a hundred small preconditions in the months before the airplane arrives: the parts, the labor, the paperwork, the owner sign-offs. That's the layer Matt called the gates, and it's what I'll write about next.