COMAT Copilot

COMAT Copilot keeps planes flying. It catches expiring and failed parts, verifies the spare is really on the shelf and books it on the airline’s own flights before it becomes an AOG.

Comment

Inspiration

My partner works in Stores, the parts warehouse side of a regional airline. Listening to him describe his shifts, I kept hearing the same story: a plane can't fly because it needs a part, the system says a spare is sitting on a shelf a few stations away, and when someone goes to get it, it isn't there.

That's an AOG (aircraft on ground), and every hour costs the airline money, crews and passengers. What surprised me is how many of them are predictable. Parts have expiry dates. Spares get miscounted because serial numbers are hand-written on paper and retyped later. And planners jump between a maintenance system, a cargo system and a shipping tool to make one decision.

I wanted to build the tool he wishes he had: one that sees the problem coming and hands Stores the answer.

What it does

COMAT Copilot is a parts response engine that keeps aircraft off the ground.

  • Catches expiring parts days early. It scans installed parts and stored lots, finds anything about to expire and plans the replacement while there's still time to ship it cheaply.
  • Responds to failures in seconds. When a mechanic writes up a broken part, it finds the nearest spare, the fastest bookable flight and the right priority instantly.
  • Ships on the airline's own flights. It compares flying the part as COMAT (company material), transferring it from another station or buying it, and ranks the options by cost and AOG risk. It respects booking cutoffs, two-leg connections and dangerous goods rules.
  • Uses the cheapest safe priority. Standard shipments while there's a backup flight, Must Ride when it's the last flight that works, AOG only when time has run out. Our pitch: turn AOGs into STDs.
  • Checks that the spare actually exists. Every inventory record gets a confidence score. Low-confidence spares trigger a quick photo check: Stores snaps the part tag and AI reads the part number and serial. A mismatch flags the phantom record and re-plans before anyone wastes a trip.
  • Fixes records at the source. A digital PickSlip replaces paper. The clerk photographs the tag at the shelf, so serials are never hand-copied or retyped.
  • Removes retyping. Once a planner approves a plan, the shipping request is pre-filled field by field, ready to review and submit.
  • Keeps a human in charge. The Copilot recommends; people approve, override with a reason or verify. Every decision is logged on an auditable timeline.
  • Re-plans live. If a flight is delayed, affected plans rerun, upgrade priority if the backup is gone and wait for approval.

How we built it

  • Backend: Python, FastAPI and SQLModel, with SQLite for the demo and a Postgres option for a pilot.
  • Planner: plain, explainable Python scoring rather than a black box, so every recommendation can be traced. Rules for priority, routing, cutoffs and dangerous goods live in editable config files.
  • AI: Claude writes the one-line reason on each plan and reads part tags from photos for verification.
  • Adapters: each airline system (maintenance, cargo, materials and shipping) sits behind a mock adapter. In a pilot, only the adapter changes.
  • Frontend: React and Vite, with a station map, Stores queue, plan cards, shipment tracker and a mobile-friendly PickSlip.
  • Data: a synthetic regional fleet of 20 aircraft and 8 stations, with seeded scenarios for every demo moment. No real airline data is used.
  • Packaging: Docker Compose, so anyone can clone the repo and run it with one command.

Challenges we ran into

  • Learning how airlines really move parts. COMAT, AOG, Must Ride, plane-side versus to-Cargo, acceptance, screening, air waybills. The first version of my planner was wrong in ways only someone who works the job would notice, so I rebuilt the logic several times as I learned.
  • Modeling real constraints. A flight isn't an option just because it exists. It has to leave far enough out to make the booking cutoff, have room and accept the part if it's hazmat, and sometimes the only route is a connection.
  • Designing for trust. Airline teams won't hand decisions to an AI. Getting the balance right between recommending and letting people approve, override and verify took real thought.
  • Keeping it realistic without real data. I built a synthetic fleet detailed enough that someone with airline experience wouldn't spot anything off.
  • Scope. Every conversation about the job revealed a new problem worth solving. Choosing what fits in a demo was its own challenge.

Accomplishments that we're proud of

  • A full loop that runs end to end: catch, decide, verify, ship and re-plan.
  • The live delay moment, where a plan loses its backup flight, upgrades to Must Ride and waits for approval on screen.
  • Catching a phantom spare with a single photo before it causes an AOG.
  • Turning a paper PickSlip and double data entry into one photo at the shelf.
  • A product that maps to how Stores actually works, because it was shaped by someone who does the job.

What we learned

  • Many AOGs aren't caused by missing parts. They're caused by records that say a part exists when it doesn't.
  • The biggest wins aren't always smarter predictions. Sometimes they come from removing a manual step where errors creep in.
  • Domain experts are the best product teammates. Each answer from someone on the floor changed the design.
  • Explainable rules plus AI for the messy parts (reading tags, writing reasons) beats a black box when trust matters.

What's next for COMAT Copilot

  • Pilot with a Stores team to measure shipments created, minutes saved per shipment and AOGs avoided.
  • Real integrations, swapping the mock adapters for the airline's maintenance, cargo, materials and shipping systems.
  • QR labels for parts, printed once a part is verified, so it can be scanned in and out the way tools already are.
  • Smarter stocking, using removal history to place spares where failures are most likely.
  • Predictive maintenance, turning aircraft sensor history into crew-ready work orders before a part fails.
  • Beyond aviation, since the same engine applies to railroads moving locomotive parts on their own trains.

Built With

Share this project:

Updates

Submission history