Design a human-in-the-loop flow for a scenario I describe.

Interviewer's scenario: "You work at a food delivery app. Customers report damaged or missing items and request refunds. We want AI to speed up refund decisions. Design the human-in-the-loop flow." Cinderhollow Eats runs ClaimLantern to do exactly that. Bianca Reyes has worked support there for two years.

How to answer this, stage by stage

Nobody is grading whether your invented feature sounds clever. They're grading whether your fast path only opens when it's actually safe to.

Let's learn

The claim form is three taps on a phone screen: what's wrong, a photo if you have one, and submit.

Cinderhollow Eats runs ClaimLantern, the feature behind that form: it reads a damage or missing-item claim and either resolves the refund on the spot or sends it to a person.

Same claim, same rep. What changed is how many of them ever need her at all.

Before ClaimLantern, every claim landed in a queue a support rep read by hand: the customer's note, any photo, the order's value, then a manual call on the refund amount. About six minutes each, and during a dinner rush, that queue backed up fast.

Now ClaimLantern resolves the majority of claims itself, in under a minute, and Bianca's team spends its time on the ones actually worth a person's judgment.

At its worst: a cluster of accounts, working together, files near-identical no-photo claims faster than anyone notices the pattern, and the auto-approve path pays every single one before a human ever sees it.

What I would leave alone: the actual refund math, item price plus the delivery fee, doesn't need touching. This whole design is about who gets to sign off, not how the number itself gets calculated.

The lesson: a fast, forgiving path is only safe as long as the thing that makes it safe, real evidence, a real pattern, stays a requirement and not a nice-to-have somebody quietly dropped.

Now here is the same thing as a story

The short version above is what you'd say defending this design to Cinderhollow's trust and safety lead. Read this one for how the loophole actually got found.

Bianca Reyes has worked support at Cinderhollow Eats for two years, long enough to read a fake damage claim by its rhythm before she finishes the first sentence.

For its first few months, ClaimLantern mostly agreed with her: whichever claims it resolved on its own were ones she'd have approved the same way, in less time than it took her to open the ticket.

Then, over one week, a cluster of about a dozen accounts started filing near-identical "wrong item" claims, no photo attached, each just under the auto-approve threshold.

Three weeks between a small, humane trade-off and a six-thousand-dollar week.

None of them individually looked unusual. ClaimLantern's leniency rule, built to reduce friction, let a missing photo slide as long as the dollar amount stayed small and the account had no recent claim on file.

By the time Bianca's weekly summary flagged an unusual spike in no-photo claims, three hundred forty of them had already been paid, a little over six thousand dollars in one week, all under the same missing-evidence loophole.

Same week, same dozen accounts. Only the requirement standing in front of them changed.

With the redesigned anchor, a claim without a photo can never auto-approve, no matter how small the dollar amount, and a customer with a recent claim on file gets routed to a person regardless of evidence. Run the same week forward: the exact same dozen accounts file the exact same no-photo claims, and every one of them lands in Bianca's queue instead of paying out on its own.

The old design asked the dollar amount to carry all the risk by itself. The new one asks for real evidence before the fast path even opens.

I removed the photo requirement because it felt like a small, humane trade, less friction for someone frustrated about a squashed order at nine at night. It took a coordinated cluster of small claims to see that the photo was never friction. It was the one thing standing between an easy refund and an easy exploit.

SPARK, in one screenNot a fraud-detection trick. SPARK is what tells you why the anchor needs two conditions, not one.

Three questions, and only a yes to all three ever opens the fast path.

Only the bottom-right corner, clear evidence and a low amount, is where the fast path is actually meant to fire.

Each of these is a real feature Cinderhollow could build eventually. None of them is this design's job today.

The recap, one line per letter: situation is a rep reading every claim by hand, payoff is trusting the common case while pausing on a real flag, anchor is two conditions before any auto-approve, risk is the missing-photo exploit, and keep out is holding back on suspension and severity scoring until this scope is solid.

And if you want to be sure it really works, try it somewhere elseSame five letters, an e-commerce returns desk instead of a delivery app. A completely different product, the same two-condition shape.

Driftwood Retail uses an AI system to decide which returned items get an automatic refund before a warehouse ever inspects the box. Dario Kessler is a returns reviewer who checks the flagged cases each shift.

Mapped onto SPARK: situation is a returns clerk today, reading every high-value return by hand, checking whether the item's condition and photo match the claimed reason; payoff is trusting auto-approval on routine, low-value, photo-backed returns, while genuinely pausing on the ones the system flags. The anchor is structurally the same idea, aimed at a different exploit: auto-approve a return only when a photo of the item is uploaded and the account shows no recent pattern of high-value returns, and anything missing a photo, above a value threshold, or flagged by account pattern goes to Dario, who sees the AI's specific reasoning. Risk is the first time an account tries wardrobing, buying, using, then returning an item, the pattern check across multiple returns catches it, not the photo alone. Keep out is no automatic account bans, no wear-and-tear scoring yet, no fraud flags shared automatically with other retailers.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "auto-approve only with a photo and a clean pattern, everything else to a person," and stop.
Cost: there's no time to build full pattern detection this sprint. Say so honestly, and ship the photo requirement first, since it alone closes the exploit that actually happened, before the pattern layer is even ready.
The model gets better, for real: if ClaimLantern's damage detection gets more accurate at reading photos, that's still not a reason to drop the pattern check, an accurate read of one photo says nothing about whether the same account is doing this every week.

Where people run it wrong.
They build one condition for the fast path, usually a dollar threshold, and let it carry all the risk alone.
They treat a nice-to-have friction reduction as free, without asking what that friction was actually protecting against.
They wait for a spike in the weekly summary to catch an exploit, instead of asking upfront what the quietest possible version of it would look like.

How to use it live. When someone hands you a feature and asks you to design the human-in-the-loop flow, ask yourself one question first: what single piece of evidence, if it's missing, should always stop the fast path, no matter how small the stakes look. Build the anchor around never letting that piece go missing.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0