Recovery, readiness and strain scores cannot be compared
A recovery score is not a measurement. It is the output of an algorithm nobody outside the vendor has seen, over inputs that differ between vendors. Two such numbers cannot be compared, and rescaling does not rescue them.
The scales, which are not all percentages
| Score | Vendor | Range |
|---|---|---|
| Recovery | WHOOP | 0–100 |
| Strain | WHOOP | 0–21, from the Borg scale — and non-linear |
| Readiness | Oura | 1–100 |
| Sleep score | Oura | 1–100 |
| Sleep performance | WHOOP | 0–100 |
Strain is the one that catches people. It looks like a percentage in a UI that shows other things out of 100, and a 14.2 rendered as "14%" is wrong twice: wrong scale, and wrong because the scale is not linear — the difference between 18 and 19 is much larger than between 8 and 9.
Why rescaling does not help
Suppose you map WHOOP recovery and Oura readiness both onto 0–1. You now have two numbers on one axis and no reason to believe a 0.7 from one means what a 0.7 from the other does.
They are computed from different inputs — different HRV statistics over (different windows), different sleep staging, different resting heart rate conventions — and combined by different undisclosed models. The output range is the only thing that was ever shared, and matching it changes nothing about the meaning.
This is worse than the HRV case, where at least the underlying quantity is defined and the difficulty is which statistic. Here the underlying quantity is whatever the vendor decided it is this quarter.
Why a z-score does not rescue them either
For HRV, the honest answer to cross-device comparison is to compare each source against its own baseline (why). That works because the underlying quantity is stable even when the statistic differs.
For a vendor score it works less well, for a reason worth being explicit about: the algorithm can change under you. A vendor that revises its model shifts the whole distribution, and a baseline computed across the change is a baseline of two different quantities. Nothing in the data marks where the change happened.
What a score is good for
- Itself, over a few weeks. Short enough that the model is probably stable, long enough for a trend.
- Ranking your own days. "This was one of my worse recovery days" is a claim the score supports.
And what it is not good for:
- Comparison with another person, whose baseline and model version differ.
- Comparison with another vendor's score, at any scaling.
- Arithmetic. Summing two days of strain is meaningless — it is already an aggregate, and adding aggregates does not produce a bigger aggregate of the same kind.
What we do with them
We store them, tagged with the vendor, the score's name, and its actual scale — so a reader knows 14.2 is on a 0–21 Borg scale and not a percentage. We never merge two vendors' scores into one series, and we never sum them.
We also do not compute our own. Turning measurements into a recovery verdict is interpretation, and interpretation of health data is a different kind of product with a different regulatory position. We say what a number is and what it can be compared with.