How would you communicate a latency regression to users?

A route that goes quiet mid-calculation does not feel careful. It feels dead, and the guess a driver makes to fill that silence is exactly the guess a safer routing model was built to stop her from making.

How to answer this, stage by stage

Nobody is grading whether you can write a friendly loading message. They are grading whether "communicate a regression" turns into an actual, threshold-driven design, instead of a promise to be transparent someday.

Let's learn

Farroute is Bearing Labs' navigation app. A driver opens it, taps a destination, and it gives turn by turn directions, picking a route it thinks is fastest and safest given traffic, construction, and reported incidents.

Before Bearing Labs added SafeRoute ML, Farroute used a lighter, purely graph-based engine. It found a route fast, a median of three tenths of a second, and even its slow one-in-twenty case finished under a second. It didn't check for a crash reported four minutes ago, or a lane closure that started an hour back. Drivers trusted it fully, glanced at the screen once, and drove.

SafeRoute ML checks live incident feeds and a short-term hazard model before it commits to a route, which is exactly why it catches things the old engine missed. That checking has a cost: a median of just under a second for a simple point-to-point trip, but a slow one-in-twenty case that can run past four seconds during peak traffic, and past seven or eight seconds on a multi-stop commercial route with several deliveries queued.

The mistake worth worrying about was never that some routes now take four seconds instead of one. It was that every one of those seconds looked exactly like nothing on screen, a blank spinner with no route line, so drivers filled the silence with their own guess: keep going off memory of the last route, or pull over and wait.

At its worst, that silence turned into a driver on the shoulder of a highway with a stalled calculation, and a truck clipping past close enough to count as a near miss. No one was hurt. But complaints tagged "app froze" rose sharply the same month, and one in every thirty peak-hour sessions ended with the driver leaving Farroute mid-calculation, switching to another map app to get moving again.

The small moment that made the silent wait impossible to leave alone.

What I'd leave alone: short trips under a couple of miles with no live incidents nearby, where SafeRoute's own median stays around a second. Adding a status line to a wait that short invents a worry that was never there, and trains drivers to distrust a message that, most of the time, means nothing.

The lesson: a quiet screen isn't neutral. It reads as either "nothing is happening" or "something is wrong," and a driver moving at speed will always pick one of those two and act on it, whichever one you didn't design for.

Now here is the same thing as a story

Read the story below when you want to feel why a wait has to say something specific, not just eventually say something. The short version is above. This is the long one.

For most of the two years Britta Solberg had run Farroute's routing product, the best part of her week was watching the trip-completion graph hold flat, high, and boring.

Britta had joined Bearing Labs when Farroute was still finding its footing against two much bigger map apps, and she'd earned her seat on every routing decision the slow way, by shipping small, careful fixes that never broke anyone's trip. Drivers didn't think about Farroute. They opened it, tapped a pin, and drove. That was the whole point.

SafeRoute ML shipped quiet and confident. It checked live incident reports and short-term hazard patterns before committing to a route, catching things the old engine simply couldn't see, a lane closed twenty minutes ago, a crash still being cleared. Early tests loved it. Wrong-turn complaints, the kind caused by routing someone straight into a closure, dropped by nearly half in the first month.

For a while, that was the whole story, and it was a good one. Traffic was light during the beta, SafeRoute answered quickly on most trips, and the extra second or two barely registered next to how much better the routes had gotten. The habit thinned out slowly after that: a slow Tuesday evening commute here, a driver muttering "did it freeze" under her breath, a second driver doing the same thing the following week without telling anyone. Nobody filed a ticket. Waiting a beat longer for a good route felt like nothing worth mentioning.

The trigger wasn't a single catastrophe, at first. It was a delivery driver, mid-route on a highway on-ramp during peak traffic, watching the screen sit blank for what felt, to her, like far too long. She pulled onto the shoulder to wait it out, the way anyone reasonably would with no line on the map and no way to know if it was still working. A truck clipped past close enough that she felt the draft of it. Nobody was hurt. She filed a support ticket that used the word "scared."

The real cost was never the four seconds. It was that Farroute, a tool built specifically to route people around danger, had gone silent at the exact moment a driver needed it to say something, and her sensible response to that silence, pulling over, was the more dangerous of her two choices.

The decision Britta would take back happened in a routing review, months before SafeRoute ever shipped. An engineer asked whether the safety pass should run separately from the base route calculation, so something could show on screen while the safety check kept going. "It's one pipeline," Britta said. "Keep it one call, we ship faster and there's less to maintain." Nobody pushed back. It made complete sense in that room, back when the whole pipeline still finished in under a second.

Run that Tuesday over again the old way, and it repeats: a stalled screen, a driver on the shoulder, a truck too close for comfort. Run it the new way: the moment SafeRoute crosses double its own normal time for that trip, a rough route appears immediately from the fast engine, with one plain line saying it's still finding the safest route. The driver keeps driving. By week eight, sessions ending mid-calculation had fallen from two hundred forty a week to twenty one, and the shoulder-pullover pattern in the logs had all but disappeared.

One design trusted that a single blocking call, once fast, would stay simple forever. The other trusted that the moment a second, slower step joins the first one, the screen owes the driver a sentence, not just an eventual answer.

What I'd tell myself, back in that routing review: "one pipeline, ships faster" was true the day we said it, and false the day SafeRoute made the pipeline slow enough that silence stopped being free.

SPARK, for a wait that has to say something

Not a checklist to recite. Each letter has to survive the same near miss the story just walked through, a driver alone on a shoulder with a blank screen.

The whole job, done by hand, before Farroute or any routing model existed.

The one screen a reader should be able to point at and say, that's the decision.

The anchor is allowed to be wrong once, as long as it says so within its own four seconds instead of nine minutes of silence.

What stayed off the day one build, and why each one waits.

Three things worth stating directly, since this is where the real judgment sits. The alternative Britta rejected was a permanent settings toggle letting drivers opt back into the old, faster engine whenever they wanted. It lost because the trade SafeRoute makes, a few extra seconds for routes that account for a crash reported four minutes ago, is exactly the trade the app is supposed to make on a driver's behalf, and a quiet opt-out would let the slowest, most cautious routes get skipped by whoever got annoyed first, which defeats the entire point of shipping it. The AI specific failure worth naming by name is silent degradation: a genuine model regression looks, on screen, identical to an app that has simply frozen, and a driver has no way to tell the two apart without being told. The guardrail is the two-check trigger itself, since every request that crosses double its own baseline gets flagged the same way regardless of cause, so a slow model and a broken one both surface the same honest message instead of staying invisible. And the quality, latency, and cost trade-off worth naming too: SafeRoute ML trades a few extra seconds of calculation time for routes that account for live hazards the old engine couldn't see, and the fallback route shown during that wait is deliberately the less-informed one, a small, stated cost, accepted openly, rather than hidden behind a spinner that pretends nothing is being traded at all.

And if you want to be sure it really works, try it somewhere else

Same five letters, a radiology scan instead of a highway, and this time the reversal is a merged pipeline again, but the person on the other end is a physician, not a driver.

ScanQueue is a triage assistant built for Corvinus Imaging. It reads an incoming scan, runs a deep anomaly check for things like a possible bleed, and re-sorts the reading queue so a radiologist sees the most urgent cases first. Fabian Oyelaran is the engineer who redesigned its wait after a model upgrade made the deep check noticeably slower.

S, situation: before ScanQueue, a technologist logged each scan into a plain first-in-first-out queue by hand, and a radiologist worked straight down the list, sometimes reading a routine scan well before a genuinely urgent one that happened to arrive later.

P, payoff: the habit worth building isn't "physicians feel informed while it processes." It's a physician glancing at a live status and trusting that an urgent flag, once it appears, is already true, so they act on it the moment they see it.

A, anchor: split the pipeline into two lanes. A fast, coarse triage pass, urgent or not, runs first and blocks, typically under eight seconds, and shows a status the instant it's done. The deep anomaly check, the part that got slower, keeps running in the background afterward, updating the same status line when it finishes instead of holding the urgent flag hostage to it.

R, risk: the deep model occasionally times out on an unusually dense scan. Without a limit, a case could sit "reviewing" for twenty minutes with no signal at all, which is worse than no AI triage in the first place, since a physician might assume it had already been checked and cleared.

K, keep out: no automatic sign-off from the deep check alone, a radiologist still reviews every flagged case by eye; and no patient-facing wait estimate, that's a feature for later, this fix is about the clinical queue, not the waiting room.

Same two-check shape as Farroute's anchor, applied to a scan instead of a route.

Same method, a different weak spot: Farroute's slow step is an added safety pass on every single trip. ScanQueue's slow step only bites on a dense, unusual scan, so the fix wasn't picking one threshold, it was noticing that a fast, always-needed question, urgent or not, had been bundled into the same blocking call as a slow, deeper one that didn't need to hold it up.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the anchor, silence under a trip's own normal time, a plain line and a fast fallback past double that, and the one number, sessions ending mid-calculation fell from 240 a week to 21.
Cost: there's no budget this quarter to build a fancy live status screen. Ship the plainest version, one line of text and a rough route, it costs almost nothing and it's the part that actually earns the trust back.
The model got better, for real: say SafeRoute ML gets twice as fast next quarter. That's not a reason to remove the message system. A route that still crosses double its own new, faster baseline still deserves the same honest line, it will just fire less often.

Where people run it wrong.
They write one message for every wait, so a driver on a two-second trip and a driver on a nine-minute outage see the exact same reassuring sentence.
They set the trigger off a single fixed number instead of each trip's own baseline, so a naturally slow trip type trips the message on every single run.
They explain the cause, the model name, the word "latency," instead of the fix, which spends a driver's attention on something they can't act on anyway.

How to use it live. Name the real split before answering: "is this asking me what to say, or asking me when to say it." Say that out loud, and it buys a beat while making clear you're not going to answer with a single friendly sentence.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0