How would you set expectations about errors during onboarding?

Say we build a kiosk. A swimmer finishes a lap, StrokeLine reviews the recorded footage, and within seconds it scores their stroke and flags anything that looks off.

How to answer this, stage by stage

Seven stages. Say each one out loud, in order, and you've got the whole answer.

Let's learn

Say we build a kiosk. A swimmer finishes a lap, StrokeLine reviews the footage, and within seconds it scores their stroke and flags anything that looks off, elbow position, kick width, breathing rhythm.

Before StrokeLine, Bekah reviewed film for every swimmer on her roster, every week, about 30 swimmers, roughly nine hours of footage. She caught real issues, but it took her whole Sunday.

With StrokeLine, review takes minutes instead of hours, and for months, it agreed with what Bekah already saw. So she started pulling film herself less often, from nine swimmers a week down to two.

The extra speed was never the problem. The problem was what happened the one time StrokeLine's flag was wrong, and nobody was still checking.

At its worst: a program-director audit pulled ten swimmers' film at random and compared it against a month of StrokeLine reports. Two swimmers had been flagged for a "flaw" that was, on closer look, just an unusual stroke that happened to work. One of them had already had three weeks of practice time spent "correcting" a problem that never existed.

What I would leave alone: for swimmers with textbook technique, the vast majority, StrokeLine's flags are reliably right. The fix isn't softening every report, it's naming the one edge where it isn't.

The lesson: an onboarding that says "it's not perfect" and stops there hasn't set an expectation at all. An expectation has to name the actual shape of the failure, or it's just a disclaimer nobody remembers by week three.

Now here is the same thing as a story

The short version above is what you'd say in an interview. This one is how it actually happened, week by week.

Her name is Bekah Lindqvist. She has coached competitive swimmers for eleven years, and before StrokeLine, she knew every stroke on her roster the way you know a friend's handwriting.

Five letters, and the third one, identify the flip, is the one worth slowing down on.

StrokeLine arrived the spring before last. For months, it was a genuine gift: Bekah could scan a report in ninety seconds instead of scrubbing through film for an hour, and when she did spot-check, it kept agreeing with her eye.

Nobody decided to stop checking. It just kept being right, week after week, until checking felt like a formality.

So she checked nine flagged swimmers on film one week, then six, then three, then one. Not out of carelessness. Out of a habit that kept getting confirmed as unnecessary.

Bekah never had a confidence percentage in her head. She had a feeling with exactly two settings: worth checking, or not.

The third beat is the quiet one. Nothing dramatic happened there, which is exactly why nobody noticed it happening.

Then, in month six, the program director ran the quarterly audit every coach knew about but nobody thought much of: ten swimmers pulled at random, film compared against a month of reports.

The audit found the problem. It did not cause it. The problem had been growing for two months already.

Two of the ten had been flagged for a "narrow kick," a flaw StrokeLine names often. On film, both kicks were unusual, wider stance, different tempo, but neither was actually a problem. One swimmer had already spent three weeks in practice narrowing a kick that had been working fine.

We did not lose accuracy. We lost the difference between a swimmer's stroke being wrong and a swimmer's stroke simply not looking like everyone else's.

The fix wasn't retraining the model on more strokes, though that helps eventually. The fix was the report itself, and a rule that didn't depend on Bekah remembering to double-check.

The second callout is the one the old report never had at all: a way to say "different" without saying "broken."

Now any swimmer flagged three times in a month gets an automatic film pull, no coach has to ask. The report itself separates "matches common patterns" from "differs from common patterns, not necessarily wrong." The same unusual kick this season got flagged, the rule triggered a film check within a week, and Bekah confirmed it was fine before a single practice got rebuilt around fixing it.

I wrote "validated against elite technique models" because it sounded confident and it was true, as far as it went. It took watching three weeks of a swimmer's practice get spent correcting a stroke that was never broken to understand that a true claim can still leave out the one thing a coach needed to hear.

The five steps, if you want to remember itNot a checklist. FLIPS is what forces you to name the actual switch, not just the number behind it.

The recap, one line per letter: find the person is Bekah reading a report each morning, locate the habit is her fading film checks, identify the flip is trusting the whole flag list instead of any of it, pinpoint the old decision is the unqualified "validated" claim, and show the replay is a wrong flag caught in a week instead of a quarter.

And if you want to be sure it really works, try it somewhere elseA different flip family this time, a solar-panel crew instead of a pool deck. The failure isn't over-trust, it's a workaround nobody asked them to build.

Andres Quilaqueo leads a solar-install crew that uses ThermaCheck, a handheld thermal-imaging tool, to spot faulty panel connections by their heat signature before a system goes live.

ThermaCheck's onboarding never set an expectation about lighting: heavy morning shadows can throw off a thermal reading enough to trigger false alarms. Nobody told the crew this directly. They just noticed, over a few installs, that early-morning scans kept flagging connections that turned out fine, and midday scans almost never did.

Nobody built this workaround on purpose. The crew found the safe corner of the chart by trial and error, and started living there.

So the crew quietly started waiting until midday to run every scan, even on jobs where an early start mattered. This is the pre-editing flip: instead of feeding the tool the real, messy conditions of the job, they learned its failure shape and started grooming the conditions to avoid it, which meant an early-morning fault, the exact case they'd been avoiding, would now never get scanned at all until midday, if the crew remembered to go back.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "name the specific failure, build a rule that catches it," and stop.
Cost: there's no budget for a rule engine this quarter. Say so honestly, and start with one line in the onboarding naming the lighting issue directly, since even a named risk beats a silent one.
The model gets better, for real: if StrokeLine's accuracy improves to 99 percent on typical strokes, the unusual-stroke gap still needs naming, a rarer miss on an atypical case is still a miss nobody is watching for.

Where people run it wrong.
They write a disclaimer once, at signup, and never repeat the specific failure shape anywhere the person will see it again.
They assume a quiet stretch with no complaints means expectations are working, when it often means the safety net already eroded.
They respond to a discovered miss by adding a general "please double-check the AI" reminder instead of a rule that triggers automatically.

How to use it live. When someone asks how you'd set error expectations, ask yourself one question first: what is the one specific, nameable way this tool gets it wrong. Say that, not "it's not always right."

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0