CaseAdvancedDesigning for Uncertainty & Trust / Designing for failure and graceful degradation / #4
How do you design a feature that degrades to a non-AI version rather than breaking?
SPARK design a real second path, not a hope that the first one always finishes
Aerlume Airways runs Farewind, an AI tool that tries to solve rebooking for an entire disrupted flight network at once. Colette Fontaine has worked airport disruption recovery for ten years. Here is the night a blizzard grounded the fleet and Farewind had no second act, and what a real one looks like.
The direct answer
Build two separate paths from day one, not one path with a hope attached. The AI path tries a full network-wide solve inside a fixed time budget. A completely independent, always-available rules engine rebooks one passenger at a time by fare class and priority tier. The moment the AI path misses its budget or errors, the system switches to the rules engine automatically, and tells the desk which mode is running.
Do this, in order
Build the non-AI rules engine as a fully separate path, not a mode inside the AI system.Why: if the fallback shares code with the thing that's failing, it can fail for the exact same reason.
Give the AI solve a hard time budget, and switch the moment it's missed, don't wait for an error.Why: a system that is quietly still "thinking" past its budget is functionally the same as one that's already broken.
Always show the desk which mode is running, and since when.Why: an agent working blind, unsure if the AI is still trying, can't decide whether to start manually or keep waiting.
Design the fallback around a unit of one, a single passenger, never the whole event at once.Why: an all-or-nothing atom is exactly what breaks under a disruption too big to solve in one shot.
Track how often the AI path actually finishes inside its own time budget, not just whether it eventually returns something.Why: a solve time that's quietly creeping up is the leading sign the fallback is about to matter.
Leave the AI path untouched for the disruptions it already handles well, most of them.Why: the fallback only has to earn its keep on the rare event big enough to need it.
How to answer this, stage by stage
Nobody is grading whether you can name a fallback. They're grading whether it still works the one night the disruption is the biggest one the airline has ever seen.
Stage 1
Scope it to one feature, one storm
Say it like this
"I'll design this for Farewind, Aerlume Airways' rebooking assistant, for the exact night a blizzard grounded the fleet and it had nothing to fall back on."
Why this works
Turns "design a graceful degradation" into one real system, one real night, instead of an abstract resilience essay.
Stage 2
Say your structure out loud
Say it like this
"I'll use SPARK. Situation, how disruption recovery worked before this tool. Payoff, the habit I want the fallback to build. Anchor, the actual two-path design. Risk, what breaks it. Keep out, what stays for later."
Why this works
Shows a repeatable method for degrading gracefully, not a single clever trick for this one feature.
Stage 3
Ground the anchor in what already exists without the AI
Say it like this
"Before Farewind, an agent took the next passenger on the priority sheet and rebooked them by hand, checking fare class and elite status against available seats, about four minutes each, but it always finished, one passenger at a time."
Why this works
Proves the non-AI path isn't invented under pressure. It's the process the airline already trusted for decades.
Stage 4
Give the anchor, the one decision
Say it like this
"Two separate paths, from day one. Farewind's network-wide solve runs inside a fixed time budget. A completely independent rules engine rebooks one passenger at a time. The moment the budget is missed, the system switches automatically and says so on screen."
Why this works
This is the direct answer, as an actual system design, not a promise that "there will be a fallback."
Stage 5
Prove the anchor survives its own risk
Say it like this
"The first time a disruption is bigger than the AI path has ever seen, the network-wide solve times out, and the rules engine is already running, working the priority queue one passenger at a time, instead of the whole desk waiting on a screen that says optimizing."
Why this works
Answers the real question underneath: what happens the one time the AI genuinely can't solve it.
Stage 6
Say what you'd measure afterward
Say it like this
"I'd track Farewind's solve time on its largest disruption each month. If that number keeps creeping toward the time budget, the fallback is about to matter more often, and that's worth knowing before the next storm, not after."
Why this works
Shows you're thinking about degradation as an ongoing risk, not a one-time fix.
Stage 7
Say what you'd leave alone
Say it like this
"Small and medium disruptions don't need a rebuild. Farewind solves those in minutes, well inside budget, and nothing about this redesign should slow that down."
Why this works
Shows judgment about scope, instead of treating every disruption as equally risky.
Stage 8
Close on the one line
Say it like this
"A feature that degrades gracefully has two real paths, built separately, from day one. A feature that just hopes the first path always finishes doesn't have a fallback. It has a single point of failure with a nicer name."
Why this works
Restates the direct answer in one breath, ready for a follow-up push.
Let's learn
Farewind is an AI tool Aerlume Airways built to solve rebooking for an entire disrupted flight network at once, matching thousands of stranded passengers to available seats across every remaining flight in a single pass.
Before Farewind, every passenger got rebooked one at a time, by hand. Slower, but it never depended on solving the whole storm in a single pass.
Before Farewind, an agent rebooked disrupted passengers one at a time from a printed priority sheet, checking fare class and connection risk, about four minutes each, but always finishing.
On an ordinary disruption, Farewind cuts what used to take a full day of manual work down to under an hour, solving hundreds of passengers in one pass.
Here's the turn: the speed was never the failure. As Aerlume's network grew, more cities, more codeshare partners, more combinations to check, Farewind's solve time had been quietly creeping up for months, with nobody tracking it as its own number. Nobody could point to the day it started. It just kept taking a little longer on the biggest disruptions, until the night it finally ran out of runway entirely.
Farewind's solve time on the largest disruption each month, past year
Nobody watched this line by itself. It only ever showed up buried inside "average recovery time," which still looked fine right up until the month the largest disruption finally blew past what a time budget would have caught.
At its worst, an entire desk full of agents sits idle for an hour and a half, watching a screen say "optimizing your rebooking," while thousands of passengers wait in a terminal with no plan at all, because nobody built anything for Farewind to hand off to.
Same storm, same ninety minutes. Only what the desk had to work with while waiting changed.
The decision I would take back
Farewind was built with one unit of work: the entire disrupted network, solved all at once. There was no smaller unit underneath it, no way to process even the passengers it was confident about while it kept working on the hard ones. That made sense while every disruption fit comfortably inside the time budget. It stopped making sense the moment a disruption came along too large to solve in one pass, with nothing smaller for the system to fall back to.
What I would leave alone: small and medium disruptions don't need this rebuild. Farewind solves those in minutes, well inside budget, and this redesign shouldn't touch that path at all.
The lesson: a fallback isn't a smaller version of the main feature. It's a genuinely separate path, built early, for the day the main one simply can't finish.
Now here is the same thing as a story
The short version above is what you'd say defending this redesign to Aerlume's operations council. Read this one for how slowly the runway actually disappeared.
For eight months, the best part of Colette's shift during a disruption was watching Farewind work. She'd load the canceled flights in, and within twenty or thirty minutes, a full rebooking plan for every passenger would appear, sorted and ready to execute.
She'd done disruption recovery by hand for years before that, and she still remembered the old rhythm, the priority sheet, the seat map, the four minutes per passenger. Farewind made all of it feel like something from a different decade.
Knowledge spark: why would an AI solve get slower as a network grows?
A network-wide rebooking solve has to check far more combinations as an airline adds routes, cities, and codeshare partners, since every new option is a possible seat for every stranded passenger to consider. The math behind that kind of search tends to get harder much faster than the network itself grows, which is why a solve that took twelve minutes a year ago can quietly balloon to well over an hour without anyone changing how the tool works at all.
Nobody was watching solve time as its own number. It lived buried inside a broader "average recovery time" metric that kept looking fine, since most disruptions were still small enough to solve fast. The one number that would have warned them, the time on the largest disruption each month, wasn't a number anyone had ever built a dashboard for.
An hour and a half between a storm grounding the fleet and the desk having anything at all to work from.
On a January night, a blizzard grounded the entire regional fleet at once, over three hundred canceled flights, twelve thousand stranded passengers. Colette loaded the disruption into Farewind at 4:05pm, same as always. The screen said "optimizing your rebooking." It kept saying that for ninety minutes.
Farewind did not fail loudly, and it did not fail quietly either. It just kept trying, past the point trying had stopped being useful to anyone standing at the desk.
At 5:35pm, the solve finally errored out, no plan, no partial result, nothing to execute. Colette and her team had to start from a blank priority sheet, ninety minutes later than they would have if they'd simply started rebooking by hand the moment the storm hit.
The old screen showed none of these four things during the ninety minutes it was optimizing. It just said one word, over and over.
With the redesigned system, the moment Farewind's solve crosses its 90-minute budget, the screen switches automatically: "Network solve over budget as of 5:35pm. Switching to manual queue, priority order below." Run the same night forward: the desk is rebooking passenger one by 4:07pm, working the priority queue by hand the entire time Farewind keeps trying in the background, and Farewind's eventual result, if it ever finishes, only replaces whatever the manual queue hasn't reached yet.
The old system asked twelve thousand passengers to wait on a single, all-or-nothing solve. The new one never stops working on them at all.
We built Farewind's solve to be thorough, on purpose, so it wouldn't miss a better combination sitting one layer deeper in the search. It took a blizzard and ninety idle minutes to see that thorough and finished are not the same thing, and a system needs a real answer for what happens when it can't be both.
SPARK, at the size of the biggest storm yetNot a lecture on timeouts. SPARK is what forces the design to survive the one disruption bigger than anything it's seen before.
S
Situation. How recovery worked before this tool.
An agent rebooked one passenger at a time from a printed priority sheet, about four minutes each, slower but always finishing.
Grounds the fallback in a process the airline already trusted for decades.
P
Payoff. The habit this should build.
Trusting that the desk always has something to work from, whether that's Farewind's full plan or the manual queue underneath it, never a blank screen.
Names the actual behavior change, not just a feeling of resilience.
A
Anchor. The one decision everything hangs on.
Two fully separate paths from day one. A time-budgeted AI solve, and an always-available rules engine working one passenger at a time, switching automatically the moment the budget is missed.
The hardest step and the direct answer: a real second system, not a hope the first one always finishes.
R
Risk. What breaks the first time it's wrong.
The largest disruption the network has ever faced. The anchor survives it because the rules engine never depends on the AI solve finishing, or even existing.
Proves the anchor was built against its worst case, not its average day.
K
Keep out. What we won't build, day one.
No hybrid mode that tries to merge a partial AI result with the manual queue. No passenger-facing explanation of their priority tier. Both are real ideas, neither is required to stop the ninety idle minutes.
Shows restraint under pressure, instead of trying to solve every adjacent problem in one redesign.
Only the bottom branch is new. The system already handled everything above it just fine.
The recap, one line per letter: situation is the printed priority sheet and four minutes per passenger, payoff is trusting the desk always has something to work from, anchor is the two separate paths and the automatic switch, risk is the largest disruption yet, and keep out is holding back a hybrid solve and a passenger-facing explainer.
Each of these is a real feature worth building eventually. None of them is required to stop the desk from sitting idle.
And if you want to be sure it really works, try it somewhere elseSame five letters, a city's residential waste collection router instead of an airline. A different all-or-nothing atom, a different hand-off.
Verdant Waste runs a routing AI that replans an entire city's residential pickup routes overnight around road closures, new construction, and reported bin issues. Tobias Renner dispatches the truck fleet each morning. Mapped onto SPARK: situation is a dispatcher today without the tool, working from last week's fixed paper route and adjusting it by memory; payoff is the habit to build, trusting that trucks always roll out with a route, whether the AI solved the whole city overnight or the fallback simply reused each truck's last known-good route.
The anchor here aims at the same failure in a different shape: if the overnight replan hasn't finished by 5:00am, every truck gets yesterday's route back automatically, adjusted only for closures logged before midnight, rather than sitting in the yard waiting on a citywide solve that missed its window. The risk the team designed against was a truck fleet with literally no route at 6:00am because the AI was still recalculating an unusually large batch of road closures after a storm.
Swap "rebooking screen" for "route sheet," and the same four parts still do the same job.
Trucks rolling out with a route by 6am, old design versus fallback design
Same storm, same overnight closures. The fallback design never asks a single truck to wait on a solve that missed its own deadline.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "two separate paths, a time-budgeted AI solve and an always-available rules-based fallback that switches automatically," and stop.
Cost: there's no engineering time this quarter to build the fallback as a fully separate system. Say so honestly, and start by simply giving the AI a hard time budget and an honest "over budget" message, since that alone stops the worst version of this failure.
The model gets better, for real: if Farewind's solve speed genuinely improves and it rarely misses budget anymore, that's still not a reason to remove the fallback, the rarest miss is exactly the one that will land on the largest, highest-stakes disruption.
Where people run it wrong.
They build the fallback as a smaller version of the AI feature, sharing code, which means it can share the same failure.
They wait for the AI path to error out instead of switching the moment it misses its own time budget.
They test the fallback only against ordinary days, never against the single largest event the system has ever had to handle.
How to use it live. When someone asks you to design a feature that degrades instead of breaking, ask yourself one question first: does the fallback share a single line of code with the thing that might fail? If yes, it isn't really a second path yet.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework fits a "design a feature that degrades instead of breaking" question?
Tap to flip
ANSWER
SPARK: situation, payoff, anchor, risk, keep out. Ground the anchor in a process that already exists without the tool, then prove it survives the worst case.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Colette Fontaine, an airport disruption recovery agent at Aerlume Airways for ten years, who used to rebook passengers one at a time by hand.
3 · THE SITUATION
How did rebooking work before Farewind?
Tap to flip
ANSWER
An agent took the next passenger on a printed priority sheet and rebooked them by hand, about four minutes each, always finishing.
4 · THE ANCHOR
What's the one design decision this answer hangs on?
Tap to flip
ANSWER
Two fully separate paths: a time-budgeted AI solve, and an always-available rules engine rebooking one passenger at a time, switching automatically the moment the budget is missed.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Building Farewind with one unit of work, the entire disrupted network solved all at once, with nothing smaller underneath it to fall back to.
6 · THE NUMBER
Fill in the blank: Farewind's solve time on the largest monthly disruption grew from about 12 minutes a year ago to about ___ minutes the month of the blizzard.
Tap to flip
ANSWER
About 84 minutes, just under the 90-minute budget the redesign would later add, and close enough that the following month's solve finally blew past it.
7 · THE REPLAY
Same blizzard, redesigned system. What changes?
Tap to flip
ANSWER
The desk starts rebooking passenger one by 4:07pm, working the manual queue the entire ninety minutes Farewind keeps trying in the background, instead of watching a blank "optimizing" screen.
8 · CROSS PRODUCT TRANSFER
Section 4 answers this again for a different product. Which product, and what's the anchor there?
Tap to flip
ANSWER
Verdant Waste's overnight route replanner. The anchor reverts every truck to yesterday's route automatically if the citywide solve misses its 5am window, instead of leaving trucks with no route at all.
Check yourself Score: 0 / 0
Short answer, name the reversal
1. What old design decision does this answer take back, and why did it make sense when Farewind first launched?
Show hint
Look at "the decision I would take back."
Show answer
Model answer: Building the solve as one all-or-nothing unit of work, the entire network at once. It made sense while every disruption comfortably fit inside the time budget.
Multiple choice
2. Why does the redesigned system switch to the manual queue the moment the time budget is missed, instead of waiting for Farewind's solve to error out?
A. Errors take too long to display on screen.
B. A solve running past its own useful window is functionally the same as one that's already failed, and waiting only wastes more idle time.
C. Aerlume's contract with its AI vendor requires it.
D. It reduces how many passengers Farewind has to consider.
Show hint
Look at the second bullet in the priority list.
Show answer
B. Switching on a missed budget, not on an eventual error, is what stops the desk from sitting idle for the full ninety minutes.
True or false
3. True or false: under the redesigned system, Farewind stops trying to solve the network once the manual queue takes over.
True
False
Show hint
Look at the redesigned paragraph in Section 2.
Show answer
False. Farewind keeps working in the background. Its eventual result, if it finishes, only replaces whatever the manual queue hasn't already reached.
Fill in the blank
4. Fill in the blank: under the old design, the desk had nothing to work from for about ___ minutes before the solve finally errored out.
Show hint
Look at the timeline diagram.
Show answer
Ninety minutes. From 4:05pm to 5:35pm, the entire desk waited on a screen that only ever said "optimizing."
Short answer, apply it yourself
5. Think of an app or tool you use that has ever frozen or spun on a task with no visible fallback. What would a genuine second path have looked like for it?
Show hint
Ask whether the tool had a smaller, simpler version of the task it could have offered instead of nothing.
Show answer
Model answer: Most people can name a tool that just spins under load. A genuine fallback usually looks like a smaller, slower, less automatic version of the same job, not a blank screen.
Short answer, where it wouldn't matter
6. Name a case in Farewind where this two-path redesign genuinely doesn't need to change anything.
Show hint
Look at "what I would leave alone."
Show answer
Model answer: Small and medium disruptions. Farewind already solves those well inside its time budget, so the fallback never activates and nothing about the redesign touches that path.
Before you close the answer
Why this works
Tests whether you'll build a genuinely separate fallback path, or just add a nicer error message on top of a system that still has one single point of failure.
Follow-up traps
"Isn't maintaining two completely separate systems just doubling your engineering cost?" Response: yes, and that's an honest, worthwhile cost. A fallback that shares code with the thing it's meant to catch isn't really a fallback, it's the same failure wearing a second name.
"What if the manual queue also can't keep up during a truly massive event?" Response: it's still strictly better than a blank screen, since it processes passengers in priority order the entire time, at a fixed, predictable rate, instead of everyone waiting on an uncertain solve that might never finish.
If pressed
Aerlume's redesigned rules engine doesn't wait for Farewind's solve to be declared over budget before it starts warming up its own priority queue in the background, so the switch itself, when it happens, costs seconds rather than requiring the manual system to spin up from cold.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
