Design the fallback experience for an AI feature when the provider is down.

Brindle Metalworks runs a line of hydraulic presses that stamp brackets for truck chassis. ClearLine Vision is a cloud-based defect-detection system its inspectors run from a wall-mounted terminal beside the press. Deshawn Okafor has inspected parts on this line for eight years. Here is what happened the day ClearLine's cloud provider went down mid-shift, and what the terminal should have done instead.

How to answer this, stage by stage

Nobody is grading whether you know what an API outage is. They're grading whether steel keeps moving safely while it's down.

Let's learn

Every part that came off Brindle Metalworks' line 3 press used to get checked one in ten, by hand, with calipers and a printed checklist, a slow but genuinely careful habit.

ClearLine Vision replaced that with a camera above the press feeding every single part into a cloud vision model, giving Deshawn a pass or fail reading in under two seconds, no sampling needed.

ClearLine replaced the second and third boxes with an instant camera reading. It never replaced what the line should do if that reading just stops.

Here's the turn: the everyday speed was never the issue. The real problem showed up the one time ClearLine's cloud provider went down mid-shift, because the terminal had no idea what to do next. It froze on its last reading, gave no warning, and the press kept stamping the whole time, since nobody had ever told it that "no answer from the model" should mean anything at all.

At its worst, a batch of parts with a hairline stamping crack ships to a customer, because the one reading the line had for those forty minutes was a stale "pass" from before the connection dropped.

Same outage, same forty minutes. Only what the terminal was willing to admit changed.

What I would leave alone: the automatic path itself doesn't need a rebuild. On the ordinary day, with the connection healthy, ClearLine's instant reading is exactly right, and nothing about this fallback design should slow that down.

The lesson: a fallback isn't something you bolt onto a finished system. It's a seam you have to leave in on purpose, or the system won't have anywhere to hand the job back to a person when it needs to.

Now here is the same thing as a story

The short version above is what you'd say defending this fallback design to Brindle's plant manager. Read this one for how quietly the risk built up.

The terminal is bolted to the wall two feet from the press, close enough that Deshawn can glance at it without stepping back from the line. For his first several years, that glance meant pulling a part, running calipers over it, checking a printed sheet.

ClearLine changed the glance into something else entirely: a green check or a red flag, updating every two seconds as parts rolled past the camera. Deshawn stopped pulling parts by hand within a couple of weeks. There was no reason to, the readings kept matching what his own eye would have caught anyway.

On an overnight shift, with the plant's newest network switch installed the week before, ClearLine's connection to its provider dropped at 2:12pm. The terminal's last reading, a green check from 2:11, stayed frozen on screen. Nothing told Deshawn it was stale. The press kept stamping.

Forty minutes between a dead connection and anyone noticing. The frozen green check looked exactly like a healthy one the entire time.

By the time the connection came back at 2:52pm, 340 parts had shipped with no real inspection at all, everyone on shift assuming the frozen green check meant the line was clean. A hairline crack in one batch, the kind the vision model reliably caught but a rushed glance wouldn't, wasn't flagged until a customer's own incoming inspection caught it two days later.

The old screen showed none of these four things during the outage. It just kept showing the last answer it ever got.

With the redesigned terminal, the moment ClearLine loses its connection, the screen switches within seconds to: "Model offline since 2:12pm. Sampling 1 in 10 by hand until connection returns. 34 parts checked, 306 held for review." Run the same afternoon forward: Deshawn is back on manual sampling by 2:13pm, and every uninspected part is tagged, not shipped blind.

The old terminal asked the line to trust a memory of a healthy reading. The new one tells the truth about the exact minute that memory stopped being current.

We built the fallback screen to be simple, on purpose, so it wouldn't distract from the automatic path doing most of the work. It took a two-day-late recall to see that simple and silent had quietly become the same thing.

SPARK, mapped to a dead connectionNot a lecture on redundant servers. SPARK is what forces the design to survive the minute the provider actually goes down.

Only the bottom branch is new. Everything above it was already how the terminal behaved.

The recap, one line per letter: situation is the one-in-ten manual sample, payoff is treating a missing reading as a signal instead of a pass, anchor is the timestamped fallback screen and its manual sampling switch, risk is the long unattended outage, and keep out is holding back an offline model and an automatic press pause.

Each of these is a genuine next step. None of them is required to stop parts from shipping blind.

And if you want to be sure it really works, try it somewhere elseSame five letters, a customer support translation tool instead of a stamping line. A different anchor, aimed at a different silence.

Correlink Freight runs a support desk where agents use an AI translation feature to chat live with drivers and customers in a dozen languages. Marisol Petrov handles overnight escalations. Mapped onto SPARK: situation is an agent today without the tool, reaching for a printed phrasebook and a short list of bilingual colleagues to call; payoff is the habit to build, treating a translation tool that's gone quiet as a reason to reach for that same phrasebook immediately, not a reason to keep typing into a chat box that isn't replying.

The anchor here aims at a different silence: when the translation provider stops responding, the chat window doesn't just stop updating, it shows "Translation unavailable since 11:04pm. Message saved untranslated. Try phrasebook shortcuts, or escalate to a bilingual teammate." The risk the team designed against was an agent typing several messages into a chat that looked normal, unaware none of it had reached the other person in a language they could read, while a delivery delay dispute sat unresolved for hours.

Swap "sample manually" for "use phrasebook shortcuts," and the same four parts still do the same job.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "detect the outage fast, name it on screen, switch to the known manual fallback," and stop.
Cost: there's no budget this quarter for a backup inference provider. Say so honestly, and start with detection and the manual fallback banner, since those cost almost nothing and catch most of the risk on their own.
The model gets better, for real: if ClearLine's underlying accuracy improves and outages become rarer, that's still not a reason to drop the fallback screen, a rarer outage is exactly the kind everyone forgets how to handle by hand.

Where people run it wrong.
They design the fallback for the outage they can picture, a few seconds, and never test the one that runs for an entire shift.
They let a stale reading sit on screen looking healthy, instead of expiring it the moment it's no longer current.
They treat "the physical process kept running" as fine, when the whole point of the tool was that the process needed watching.

How to use it live. When someone asks you to design a fallback for when the provider is down, ask yourself one question first: what does the physical world keep doing while the software goes quiet? Design the fallback around that, not around the API call.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0