← Back to Blog
2026-04-13· 7 min readJumpOnionAI EngineeringDebugging

Day 2: 6.47 Seconds of Air Time (The Jump Lasted 0.7)

Hand-drawn figure-skating debugging panels moving from noisy signals to a clean result.

Day 1 ended with a Python script that could extract pose data from a figure skating video. Day 2 was supposed to be the victory lap — detect the actual jump, measure air time, and celebrate.

Instead, my first jump detection algorithm reported 6.47 seconds of air time on a triple Axel that lasted about 0.7 seconds. Not "a little off." Off by an order of magnitude.

Visual thesis map
01
The obvious metric failed in the real world
02
Smaller tweaks created fake progress
03
The SOP forced a strategy switch
04
A different physical signal worked
05
The lesson was the debugging pattern

Attempt #1: Track the Obvious Signal

The approach seemed obvious. A skater jumps, something moves up, then comes back down. Track the most obvious motion signal across frames, find the peak, measure the duration. Simple physics.

On lab footage — a person jumping straight up in a controlled environment — this works beautifully. Clean parabolic arc, easy peak detection, accurate timing.

On real rinkside footage, it was a disaster. The camera moves. The skater travels horizontally across the ice. Other skaters cross the frame. The obvious signal turns into noise, and the algorithm interprets every camera jitter as the skater leaving the ice.

Diagram 02

controlled footage

A simple signal can look elegant when the environment is clean.

rinkside video

Camera motion, travel, and background noise turn elegant into false confidence.

Result: 6.47 seconds of air time. The algorithm was tracking camera shake, not the jump.

Attempt #2: Same Approach, Smaller Tweaks

The natural reaction: smooth the signal. Add a moving average filter. Increase the minimum peak prominence. Tweak the threshold.

This is where most debugging goes wrong — and where my SOP saved me. The second attempt produced 4.2 seconds of air time. Better, but still absurd. A real triple Axel is well under a second.

The problem wasn't the filter parameters. The problem was the entire approach. The obvious metric worked in controlled footage and broke on real rinkside video. Camera movement plus the skater's horizontal travel made the signal meaningless. No amount of parameter tuning fixes a wrong algorithm.

The SOP Kicked In

My workflow has a rule called Blindspot Interception: after two identical failures, force a root cause analysis. After 30 minutes on a dead-end approach, force a strategy switch. Don't tweak — rethink.

On the third attempt, instead of smoothing the same broken signal again, the system did something different. It asked the right question: what physical signal actually indicates a skater is in the air?

Without the SOP: I would have spent the entire day tuning filter parameters on a fundamentally broken approach. The first signal looked reasonable — it was just wrong for this specific domain. Without a forced strategy switch, reasonable-but-wrong can consume unlimited time.
Diagram 03
without rule
tweak
rerun
slightly better
still wrong
rule
with rule
root cause
switch frame
new evidence
correct path

Attempt #3: Track What Matters

The answer was embarrassingly simple once you know it: track a different physical signal — one inherently resistant to camera movement. The system stopped asking the video for a generic motion curve and started asking it for evidence that matched the actual skating moment.

Combined with domain constraints — the skater has to leave the ice and come back down — the noise from camera movement was filtered naturally. The wrong signal made every wobble look like a jump. The right signal made the fake jumps disappear.

Result: 0.72 seconds of air time. Within the expected range for a real triple Axel from rinkside footage.

The Debugging Pattern

What made Day 2 instructive wasn't the fix — it was the failure mode. Here's the pattern:

Diagram 01
attempt 1
wildly wrong
attempt 2
less wrong
SOP trigger
stop polishing
attempt 3
different signal
  1. Attempt 1: Algorithm produces wildly wrong result (6.47s).
  2. Attempt 2:Same algorithm with parameter tweaks produces slightly less wrong result (4.2s). Developer thinks they're making progress.
  3. SOP trigger: Blindspot Interception fires — two failures on the same approach means the approach is wrong, not the parameters.
  4. Attempt 3: Completely different approach. Correct result on first try (0.72s).

The dangerous moment is Attempt 2. The numbers improved, whichcreates the illusion of progress. Without a forced strategy switch, there would have been an Attempt 3, 4, 5 — each slightly better, none correct, each consuming another hour.

Without SOP

Keep tweaking the same broken tracking metric. Each attempt takes 45–60 minutes. After 4–5 attempts and a full day, maybe discover the approach is fundamentally wrong. Maybe not.

With SOP

Blindspot Interception after 2 failures. Force root cause analysis. Switch to a different physical signal. Correct result within 30 minutes of the strategy switch.

What I Learned

Day 2 taught me the most important debugging principle in AI development:

  1. Improving wrong numbers feels like progress. 6.47s → 4.2s → 3.1s → ... still wrong. The trajectory of improvement tricks you into staying on a dead-end path.
  2. Domain knowledge beats algorithm sophistication. The fix wasn't a better filter or a smarter model — it was understanding what "being in the air" physically looks like in a messy rinkside video.
  3. Forced strategy switches save days. My AI partner would have happily kept optimizing the first metric forever. The rule that forced a rethink after two failures is what rescued the session.

Sometimes the right answer is embarrassingly simple — you just need a system that forces you to stop polishing the wrong ideabefore you've wasted a week on it.

Next: Day 3 — months later, the AI confidently deleted production code labeled "dead." 987 tests passed. The deploy went green. Thirty hours later, a paying customer noticed.

Want the methodology behind JumpOnion?

Templates, SOPs, and enforcement hooks — from $39.

See Pricing