AI Scheduling
Recommend a Schedule:
Getting Experts to Trust a Schedule They Didn’t Build
On paper it's an optimization problem. In practice, the whole thing turned on trust.
Visuals have been white-labeled to protect client confidentiality
Impact at a glance
Cut crew-schedule building from hours to minutes
Gave schedulers a clear "why" behind every suggestion
Kept humans in command of every call with override built into the core flow
Recognition & Publication
First government-accredited, web-based algorithm-backed collaborative scheduling application
22nd International Symposium on Aviation Psychology (ISAP) 2023 · co-authored proceedings paper on human factors and AI-assisted scheduling
Highlights
- Reframed an optimization feature as a trust-and-control problem, the single decision that shaped the entire interaction model
- Made every recommendation explainable, showing the constraints and trade-offs behind each assignment so experts could verify, not just accept
- Made override a first-class action, so human judgment and machine optimization could work on the same schedule without fighting each other
- Designed for disruption: recommendations that re-flow gracefully when plans change at the last minute
- Partnered with engineering and research to validate the model against the experts who actually do the work
Visuals have been white-labeled to protect client confidentiality
Context
"An AI that builds your schedule" sounds like a button you press.
It's really two problems fighting each other. The first is optimization: a crew schedule has to balance qualifications, crew rest, training currency, aircrew availability, and fairness all at once. The second is trust: a scheduler with years of unwritten knowledge, who owns the fallout when a crew is wrong, has to sign off on a call they didn't make by hand.
The second problem is the hard one, and nobody sees it coming. Across multiple units planning hundreds of flights and events, a single recommendation the scheduler can't explain or undo gets expensive fast.
I led the design end-to-end and treated it as a trust problem, not a scheduling one: the engine had to explain itself and be easy to override, so the scheduler stayed in control of every call.
Problem & Opportunity
Before this existed, scheduling was a manual craft.
Crews were planned by hand for years on physical whiteboards covered in movable "pucks," and later in spreadsheets, usually by someone doing it as an extra duty on top of their other jobs. The information they needed lived in a dozen places: who was qualified, who was rested, who was deployed or on leave, who needed training to stay current. Holding all of it in one head was exactly the kind of work software is supposed to absorb.
The real complexity showed up when plans broke. A single mission change could cascade through an entire schedule and scrap two weeks of work built over days, sending the scheduler back to square one.
And even a flawless schedule could fail for reasons no model can see. Experts carry constraints a rulebook never captures: which crew members complement each other, who's quietly overloaded, which pairing makes for the safest flight. An engine that just handed down the "optimal" answer would either miss what only the human could catch, or be right and get rejected anyway, because nobody trusts a black box.
So the opportunity was simple. Let the expert say what they need, let the engine do the math, and design the seam between them so the human always stays in command.
Visuals have been white-labeled to protect client confidentiality
Solution
The design work went into two things: making the engine's reasoning visible, and making its decisions reversible.
The optimizer could already produce a mathematically optimal answer in seconds. That part was solved. But a schedule an expert can't see into, or can't undo, is one they won't put their name to. And here, a name on a schedule means responsibility for the crew that flies it.
Visible. Every recommendation surfaces its why, which constraints drove it, why this person over another, where it's fragile. Accepting a schedule becomes an act of verification.
Reversible. Override is a first-class action, not an escape hatch. A scheduler can change any assignment and the engine re-flows everything around it without throwing out their manual calls. Nothing takes effect until a human accepts it: the system proposes, the scheduler decides, every time. And that accept-or-reject loop pulled double duty: it taught the model which patterns experts actually trusted.
Working closely with engineering and research, I grounded the model in how scheduling really works: including the implicit constraints, like crew pairing and quiet overload, that never make it into a rulebook.
Visuals have been white-labeled to protect client confidentiality
Results
- User impact. A two-week schedule that took days to build by hand, and had to be rebuilt from scratch when a mission changed, now resolves in minutes and re-flows predictably when plans shift.
- Trust. Schedulers consistently trusted recommendations that were based on training requirements and availabilty to assess the best crew compliment.
Visuals have been white-labeled to protect client confidentiality
Reflection
Trust turned out to be an interface property, not a model property. The most important thing I designed wasn't a recommendation. It was the explanation of one. The work that mattered most happened at the moment someone disagreed with the engine: making that disagreement easy, legible, and consequence-free is what made the recommendations worth trusting at all.
The hardest lesson, though, was about a call we got wrong. Much of the data needed for good recommendations lived in other platforms we weren't integrated with. We faced a choice: build those integrations first, or build the AI tool and connect the data later. Stakeholders chose the tool knowing the risk. The cost showed up fast: users had to re-enter data they'd already entered elsewhere, and a scheduling tool is only as good as its inputs. Garbage in, garbage out — except the "garbage" was a manual burden we'd asked busy people to take on. Many didn't.