The first live run: the research meets the belt
Two earlier Lab notes made measurable promises — that reaching a heart-rate zone should take minutes, not twenty, and that the belt should park you at a point inside the zone rather than its bottom edge. This weekend a 52-minute run on real hardware measured both. It also measured something we didn't plan: what happens when a command to the belt quietly goes missing mid-workout.
The two promises
Reaching the zone argued that the old wait-and-see control took roughly twenty minutes to bring a heart rate into its band, and that a guarded 20-second approach ladder should do it in six to seven — in simulation. Inside the zone argued that once you arrive, the belt should hold you at an entry target placed 40% of the way up the band, because any controller that goes quiet inside a range otherwise settles on the range's own bottom edge.
Simulations are how we decide what to build. They are not evidence that it works. This project runs under a house rule blunt enough to print: evidence is a log, not a claim — every behaviour change ships with a human test on real hardware, and the test closes only with a diagnostic log, pinned by its SHA-256 hash. This note is the first time the heart-rate stack ran end to end with a person on the belt. One runner, a wrist heart-rate sensor, a 5 km Zone 2 program: five minutes of fixed warm-up, then a 138–148 bpm band with the speed dial handed to the governor, then a cool-down.
What the log measured
Zone entry: 5 minutes 59 seconds from the first fresh heart-rate sample — squarely inside the simulation's promised six-to-seven minutes, against the old method's ~20. The heart rate started 31 bpm below the band, and the ladder took ten steps to close the gap: 0.2 km/h at a time at first, refining to 0.1 as the readings closed in, each step waiting out a settle period before the next.
Overshoot: none. The highest reading during the whole approach was 138 bpm — the band's exact lower edge. The guard that slows the ladder near the target did the thing it was designed for.
Parked at 0.39 of the band. Inside-the-zone's whole argument was that the app should hold you at 40% of the band's width, not at its bottom edge. The measured average position across half an hour was 0.39; the median reading was 142 bpm — the entry target itself, to the beat.
One intervention in 33 minutes. From the moment the entry target was reached to the start of the cool-down, the governor changed the speed exactly once: a single 0.2 km/h reduction after the run's only above-band drift, half an hour in. Time in band after entry: 94.5%. A controller that holds a 10 bpm window on a human being with one nudge in half an hour is not hunting — and not hunting was the design goal the whole time.
The command that lost itself — and came back
The run also exercised something we never schedule: a failure. At the cool-down boundary the program asked the belt to slow from 7.2 to 5.0 km/h, and that command was accepted, queued — and then rejected at the wire, a tenth of a second later, by the app's own safety re-authorization. The technical cause is a family of bugs we spent the weekend hunting: a command whose own side effects change the safety policy it was approved under, so by the time it reaches the belt, the system considers it stale.
Here is the part worth writing up. The day before, we shipped a watchdog built on one principle: a lost command may be a bug — a silent one may not. The runner now re-reads the fate of every motion command it believes it submitted. When the cool-down's command died, the watchdog noticed within one second, re-issued it through the full authorization path, and the second copy went through. The belt slowed; the cool-down ran; the runner on the belt noticed nothing. The log recorded all of it: the rejection, its reason, the retry, the success.
That is what we actually mean by reliability. Not that nothing fails — this failed — but that failure is detected, named, bounded, and written down. The root cause is filed and will be fixed properly; the net that caught it stays either way.
Why these numbers are trustworthy
Every figure above was recomputed from a single diagnostic log with a pinned hash
(SHA-256 b62a88e9…aa4dcb), written by an app build that stamps its own source
revision into the log — so the numbers, the code that produced them, and the workout they
came from are one auditable chain. Nothing here is a screenshot of a fitness app's summary
screen.
And the weekend that led here started with the opposite: ten program starts that failed in complete silence — no error, no log, no workout record. The fixes that followed all passed the same discipline: every new test is mutation-verified (we re-break the rule on purpose and confirm the test fails), every safety constant is bracketed by tests one unit above and below its value, and every guard that caught a bug stays exactly as strict as it was. The lesson we keep re-learning: green tests are a claim; the log is the evidence.
What's next
Two legs remain deliberately untested, and both wait for a harder workout: the 92% force-down ceiling (this run's maximum was 160 bpm, far under the runner's 167 ceiling) and a manual takeover in the middle of an approach. The next run moves to the iPad console with the same watch — same program, different screen, one more layer of radio in the chain. The Lab will report what the log says, either way.