The Readiness That Belonged To Yesterday
Three field families from one vendor described three different days. Joined into one row each, they produced a recommendation aimed at the wrong night.
A wearable API returns daily metrics for day D, sleep for the night that began on D but filed under D+1, and a readiness score computed for the morning of D. Joined naively into one row per day, readiness sits one day out of step. The tell was a correlation of −0.229 against same-row sleep and +0.792 against the previous row, n = 29. The same subsystem also exited 0 on a half-empty payload, 78 KB instead of 230 KB.
Symptom
A morning readiness score of 12 out of 100 appeared in the same table row as a night the table itself described as adequate. The agent read the row as written, concluded the person was under-slept, and recommended dropping a planned training progression.
The recommendation happened to be right. The reason given for it was wrong, and that is the more expensive of the two.
Root cause
The vendor does not file every field against the same day. Three families, three conventions:
daily metrics (steps, resting heart rate, stress, battery) → day D
sleep → the night that began on day D, filed by the vendor under D+1
readiness → computed for the morning of D, from the night before
Joined into one row per calendar day — the obvious shape, and the shape every dashboard wants — readiness ends up offset by one against sleep. Every row is individually plausible. Nothing is null, nothing is out of range, and no error is raised. The join is simply describing two different nights in one line.
It stayed invisible because each row still reads sensibly on its own. It only becomes visible when you stop reading rows and start correlating columns:
Correlation of readiness with sleep in the same row: −0.229
Correlation of readiness with sleep in the previous row: +0.792 (n = 29)
A negative correlation between sleep and next-morning readiness is not a finding about physiology. It is an alignment bug wearing the costume of one, and it is the kind of finding an agent will happily write three confident paragraphs about.
Cost
One wrong attribution and one recommendation delivered with a fabricated cause. Small in isolation — but when the alignment was fixed, the actual driver turned out to be 31 hours of accumulated recovery time from two sessions the previous day, not sleep debt at all. The two have opposite remedies: sleep debt is answered with rest, recovery backlog with time and light movement.
Right advice, wrong reason is the most expensive class of error an agent produces, because nothing downstream contradicts it. It survives review, it gets repeated, and it quietly trains the reader to accept the next explanation from the same source.
The same subsystem produced a second, quieter failure in the same week. The scheduled pull ran at 07:00, before the watch had synchronised overnight. The API returned an empty skeleton rather than an error. The job exited 0, logged a successful run, and wrote a day with steps present and sleep missing. Downstream, a single missing sleep field suppressed the entire block in the morning briefing — one absent value, whole panel gone, no warning anywhere. The only reliable tell was payload size: 78 KB instead of roughly 230 KB.
Fix
Derive the alignment, do not read it from the documentation. Two correlations against neighbouring rows, computed once, settle it in a way no field name can. It took one line of code and it is now the first thing run against any new vendor feed.
Never mark a day complete on partial data. A day counts as written only when it holds both a step count and a sleep record. Anything less stays open and gets picked up by the next backfill, so a hole never becomes permanent.
Run the pull twice. A second job later in the morning costs nothing on a good day — the completeness rule makes it a no-op — and repairs the race on a bad one.
Assert on payload size. A response an order of magnitude smaller than normal is a failure regardless of status code.
Prevention
Three rules came out of this, and none of them are about wearables.
Before interpreting a single row of any joined time series, verify empirically which day each field belongs to. Vendors document this inconsistently or not at all, and a plausible row is not evidence of a correct join.
A job that exits 0 on half its data is worse than a job that crashes. A crash gets investigated the same morning; a silent success gets believed for as long as nobody counts bytes. Success criteria belong on the content of the response, not on the absence of an exception.
When a correlation comes out backwards, suspect the join before the world. Physiology, markets and customers rarely invert. Timestamps do it constantly.
See also
the-agent-that-runs-a-body · empty-is-not-zero · scheduled-tasks-that-fail-loudly · the-fallback-that-lied
$ head -12 the-readiness-that-belonged-to-yesterday.md
$ cite the-readiness-that-belonged-to-yesterday
Citation id SV-9924 is stable. It resolves at
https://stillvalid.dev/c/SV-9924 even if this artifact moves to another section,
which a bare URL does not survive. The verification date is part of the citation on
purpose — this site says out loud when it last checked.
[The Readiness That Belonged To Yesterday](https://stillvalid.dev/failures/the-readiness-that-belonged-to-yesterday) — stillvalid, SV-9924 (failure, verified 2026-08-25)