The problem
Aircraft maintainers troubleshooting a fault code had two resources: a paper manual and their own memory of what usually worked. The aircraft's own repair history lived in logs that were often paper and didn't reliably travel with the aircraft — a maintainer might have that history in hand, or might not, with no way to know in advance. Two maintainers could hit the same fault and land on two different fixes, with no reliable way to know which approach the aircraft's own history would have favored.
This program was brought to me to lead — Honeywell had already identified the opportunity and lined up an AI/ML vendor. My job was to turn it into something a maintainer would actually use.
My role
I was technical product owner and designer, leading two engineers and managing our relationship with the vendor providing the underlying AI. The vendor, my engineers and I worked as one team: they built the model that ingested the maintenance manual and repair logs, I designed the experience end to end, and we reviewed the model's output together and pushed back on it when a suggestion didn't hold up. My engineers built to the designs I specified.
Designing for trust, not just accuracy
The easy version of this product would have just shown a maintainer "the answer." I didn't think that was the right call, and it wasn't what the vendor's model was actually good at — it was good at surfacing candidates, not certainty.
So I designed around three sources instead of one: suggestions prescribed directly by the manual, suggestions drawn from repair history, and suggestions where both agreed — each carrying its own confidence score. A maintainer could see not just what the system was recommending, but where the recommendation came from and how sure the system was. Getting that distinction visible on screen mattered more than getting any single recommendation right.
What maintainers told us
Before we went further, I took the concept to four maintainers. The response was consistent, and it confirmed the instinct behind the design: they'd look at what the app suggested, then check it against how they'd normally approach the repair, before acting on it. Nobody was going to hand a fault over to a recommendation engine sight unseen. Trust had to be earned in the interface, not assumed — which is exactly what the source-and-confidence approach was built to do.
This was 2018. Confidence-scored AI recommendations are closer to standard practice now. At the time, we were designing for a level of skepticism the underlying technology hadn't yet caught up to.
What we built
No screenshots survive from this project — what does is a walkthrough of the coded application, showing the troubleshooting flow end to end: a maintainer opening a session, reviewing suggestions grouped by source and confidence, and working through the recommended steps.
What happened
We built a working version and took it to a customer. The airline passed, and Honeywell leadership shelved the program shortly after. I moved on to lead a different initiative.
What it led to
The idea didn't end at a screen. Working with one of Honeywell's AR specialists, I co-led a small team of engineering interns on a follow-on concept: a maintainer wearing AR glasses would look at an aircraft by tail number and be guided directly to the fault, then see repair steps once they arrived. We ran out of time to take it further, but it pointed at something real — getting guidance out of an app and into the physical space where the work happens.
Around the same time, I designed a smaller, parallel exploration: a Bluetooth-connected caliper that let a maintainer measure brake wear-pin length directly against the app, rather than relying on visual inspection alone. Honeywell's marketing team later packaged it into a product brochure — evidence the concept had real internal traction — but as far as I know it stayed a physical prototype and never shipped.
What I learned
Explainability isn't a feature you add once the recommendation works. It has to be the thing you design first, especially with users whose judgment is the actual safety mechanism. The maintainers we talked to weren't resistant to AI — they were doing exactly what a good maintainer should do with any new tool, which was refuse to trust it blindly.
I also learned how early this was. The industry's appetite for AI-assisted recommendations hadn't caught up to what the technology could already do in 2018. Being early isn't the same as being wrong — a lot of what felt ahead of its time then is closer to standard practice in aviation software now.