An AI system that diagnoses figure-skating jumps — designed, directed, and verified end-to-end.
A product I designed and operate, live with paying subscribers. A skater uploads a phone video; the system analyzes the jump, a human expert reviews the high-stakes calls, and the result comes back as language a parent and a nine-year-old can act on. This page is about the judgment behind it — deliberately not the blueprint.
Everything shown is my own skater, recorded with consent and with faces mosaicked — the same scrubbed footage already public on the live product. No other customer's footage or data appears anywhere on this page — and no internal thresholds, pipeline details, or implementation specifics do either. Throughout, “the skater” and “a world champion” are anonymized, and drill names are generalized.
A skater and parent can't see what's actually wrong with a jump, so they train blind; a coach can see it, but their time is expensive and limited. The hard part isn't reading one number — it's deciding which calls a machine is allowed to make at all. Rotation defects are subtle enough that a plausible-sounding guess is easy, and a confident wrong diagnosis is worse than none. The product is built around that judgment: decide what a machine may say, put a human on the high-stakes calls, and stay quiet when unsure.
Defined by what it refuses to say.
The hard part of this product isn't analysis — it's making sure a confident-sounding answer can never outrun the evidence. Every high-stakes call has a human on the path, and when the system isn't sure, it says less. That discipline is the product.
The detailed architecture — what measures, what decides, and exactly where the AI is and isn't allowed to act — is deliberately not published. It's the product's competitive core, and this page has been scrubbed of it on purpose. If you're evaluating my work and want the deep dive, I'm happy to walk through it in a conversation.
The skater's own double loop, faces mosaicked. The same engine runs on this jump as on every customer upload.
What the product does — and the calls behind it.
Live with paying subscribers. A skater uploads a phone video and gets back a diagnosis a parent can understand and a personalized training plan a coach would recognize — in about a minute, for a fraction of the cost of rink time.
The rule that sits at the top of the product: “可以少，不要错” — it can be less, but it cannot be wrong. A confident wrong diagnosis is worse than silence, so the system is built to say less when it isn't sure. I accepted a less talkative product to get a trustworthy one.
High-stakes rotation calls (under-rotation, cheated takeoff) are never auto-displayed — a human expert reviews thembefore a skater sees them. That's a promise the product enforces, not a disclaimer.
Early on, a world champion's textbook triple was flagged as an under-rotation risk. That one wrong call defined the product: I chose restraint over sensitivity, and that class of call now goes to a human instead of to the screen.
When a beginner's deep-knee landing was mis-called a “fall,” I didn't nudge a threshold — I isolated the root cause, changed the product behavior where it mattered, and verified the fix against real falls.
A deploy once removed a route labeled “dead code”; uploads silently failed for ~30 hours while the whole test suite stayed green — because nothing asserted the route existed. The fix wasn't just re-mounting it: I changed how the system verifies itself, so that class of silent failure now surfaces in minutes, not hours.
It wasn't written in a straight line.
The product was forced into shape by a string of setbacks. None of the turning points was “a cooler model” — every one was a judgment about trust. Each pain became a permanent rule.
“All tests green — but production was analyzing nothing”
The painThe eval path and the production path quietly diverged; users were handed a “result” computed on empty input.
The callI made production-parity verification a standing rule: code exists ≠ the path is verified.
A world champion’s textbook jump was flagged as a severe defect
The painOne false positive defined the entire product's safety philosophy.
The callThe first rule — “it can be less, but it cannot be wrong”: when the system isn't sure, it stays silent and a human makes the call.
A confident “dead-code” deletion silently broke uploads for ~30 hours
The painEvery test passed — because none asserted the route existed.
The callThe fix wasn't just re-mounting the route: I changed how the system verifies itselfso that class of silent failure is caught in minutes — and “dead code” claims now require proof.
A destructive “reset cache” operation damaged already-generated content
The painMulti-level caches that should have failed independently were wiped together by a single query.
The callDestructive operations now have to show exactly what they're about to touch before they run— and risky migrations get a human review matched to the size of the business.
The four calls that define the product.
Restraint as a feature
When the system isn't sure, it says less. A wrong-but-confident diagnosis is treated as the one unforgivable failure — and that priority shapes everything the skater sees.
Human-in-the-loop where it counts
High-stakes calls are reviewed by a human expert before anyone sees them — enforced by the product, not by a disclaimer.
Calibrated, not patched
False positives and over-calls were caught against real video and fixed at the root cause — an ablation to find why, not a threshold nudge to hide it — with real falls still detected.
Operator-grade reliability
A ~30-hour silent outage became a permanent lesson in self-verification: that whole class of failure now surfaces in minutes instead of hours.
- 01Designedthe product's trust architecture — which calls the system may make, which ones a human must review, and what the AI is never allowed to decide.
- 02Directed the AI build — wrote the specs, set what the LLM may and may not do, reviewed the output, and decided what shipped.
- 03Verifiedit end-to-end — caught the false positive on a world champion's jump, the beginner-fall over-call, and the dead-code outage before they defined the product.
This is how I work: design the system, draw the trust boundary, own the verification.
If you're evaluating someone to design or operate AI-augmented systems, this is a representative piece of how I think. There's more in the collection.