[ryanbr]

Implements #823.

The bug

Both platforms read a second's R-R intervals sorted by value:

ORDER BY ts ASC, rrMs ASC, seq ASC

Sorting makes adjacent values similar by construction, and RMSSD is built entirely from successive differences. So this is a one-directional downward bias in a headline metric that feeds Charge. On the issue's five-beat example:

order	beats	RMSSD
emission	812, 795, 840, 801, 833	34.85 ms
magnitude (shipped)	795, 801, 812, 833, 840	12.72 ms
		−22.14 ms

~1.1% of same-second groups on 5/MG.

The fix

A new ord column: the beat's position among all beats sharing its ts, stamped at decode time, leading the read sort.

Why not ORDER BY ts, seq (the fork's two-line version): it assumes seq is an insertion counter. It isn't — assignRrSeq keys on (ts, rrMs), so seq counts repeats of an identical beat and every distinct beat in a second carries 0. They'd all tie and the order would become whatever the scan returns, trading a deterministic wrong order for an undefined one. RMSSD could then vary between reads of the same data.

Why ord isn't in the key. The key stays (deviceId, ts, rrMs, seq). A per-second insertion counter in the key restarts per batch and collides distinct beats arriving in separate flushes — the data-loss regression assignRrSeq's own comment warns about. ord never decides which rows survive.

Legacy rows stay NULL. The order was never recorded, so it can't be backfilled, and a guess would assert something nobody observed. SQLite sorts NULL first in ASC, so an all-legacy second ties on ord and falls through to the old (rrMs, seq) order — existing data reads back exactly as before. No COALESCE, no sentinel.

Parity

Room v23→24 and GRDB v30-rr-ord, both additive nullable ALTERs — no table rebuild, no row touched. I extracted the ORDER BY from both sources and compared token-by-token, then ran both against real SQLite:

Kotlin ORDER BY: ORDER BY ts ASC, ord ASC, rrMs ASC, seq ASC
Swift  ORDER BY: ORDER BY ts ASC, ord ASC, rrMs ASC, seq ASC
Kotlin  v24+ [812, 795, 840, 801, 833] RMSSD 34.85 | legacy [795, 801, 812, 833, 840] RMSSD 12.72
Swift   v24+ [812, 795, 840, 801, 833] RMSSD 34.85 | legacy [795, 801, 812, 833, 840] RMSSD 12.72

Also in scope

• Raw-CSV export ordered by ts alone, leaving same-second beats undefined — identical data could export two different ways. Now uses the same clause.
• Stale doc: RrInterval's PARITY NOTE said the Swift key widening was still pending. It shipped as v24-rr-seq.

Testing

Swift tests run in CI (swift-packages.yml covers Packages/**) and cover this end-to-end: emission order restored, RMSSD back to 34.85, legacy NULL rows unchanged, mixed seconds deterministic across repeated reads, ord absent from the primary key. Added one test-only seam to write a legacy NULL-ord row, since the normal path always stamps it and the existing-data fallback is the branch most worth testing rather than assuming.

Checked every existing R-R read assertion: ReadTests seeds ascending so it still passes (now for a different reason — noted in a comment), and the store-backed analytics test seeds one beat per second, so ord is always 0.

Not verified: the Kotlin half is unrun. There's no SQLite driver on the JVM unit-test classpath, so those tests assert migration shape and the pure stamping function only, and android.yml is disabled so nothing compiles it. The SQL itself is identical to the Swift clause that CI does execute.

Performance: the sort no longer matches the PK index (ts, rrMs, seq), so SQLite sorts. At this query's size (a night, ceiling 200k rows) that's tens of ms; I'd rather measure than add a covering index to a large table pre-emptively.

Open question from the issue that this does not settle: whether a real night shows the 1.1% figure translating into a meaningful nightly RMSSD delta. The fix is correct regardless, but that number would tell us whether it matters clinically.

[ryanbr]

Re-review found a defect that made the store fix ineffective on iOS. Pushed.

Every analytics entry point re-sorts R-R by ts before computing RMSSD — deliberately: "the table read is already ordered, but we don't assume it". Swift's sorted(by:) is explicitly documented as not stable, so that defensive re-sort was free to re-scramble the same-second beats this PR just put in emission order — reintroducing the bias at the point of use, after the store had removed it.

It is stable in practice today (timsort since Swift 5), which is precisely why this would not have surfaced in testing. A headline metric resting on an unguaranteed stdlib implementation detail.

The asymmetry is the tell: Kotlin already stated the requirement — HrvAnalyzer carries the comment "Stable on equal ts", and sortedBy delegates to java.util.Arrays.sort, which is stable by contract. Swift had the same need and no such guarantee.

Added Array<RRInterval>.sortedByTsStable(), decorating with the original offset so the comparator is total and no two elements compare equal — stability becomes a property of our code rather than of the stdlib. Applied at all seven R-R sort sites: HRVAnalyzer.rollingRmssd, HRVFreqDomain, SleepStager, SleepStagerV2, AnalyticsEngine (×2), ShortcutHealthExport.

Left alone: the hr/gravity/steps ts sorts. Those streams carry one sample per second, so there are no ties for stability to preserve.

All 9 jobs green, including the new WhoopProtocol tests.

[ryanbr]

Third pass. My previous sweep was receiver-anchored (rr.sorted), which misses sorts chained across lines. Re-scanned by enclosing function signature instead — every .sorted inside a function taking [RRInterval] — and found two more.

1. SleepStager.respRateFromRR (rr.filter{} newline .sorted{}). This one matters more than most: step 2 reconstructs beat times by cumulative sum, so the order of a second's beats shifts every subsequent beat time and with it the RSA respiration estimate. Kotlin already used sortedBy here, so it was a live parity divergence too.

2. ResonanceEngine.scorePace — sorts sample.rr and feeds cleanRR → RMSSD. Also stable on Kotlin, unstable on Swift. This one is not in #823's store-read chain (RrBeat comes from the live paced session, not rrIntervals()); fixed because it's the same bug, not because the store fix needs it.

The scan confirms these were the last: every other ts-sort inside an R-R-taking function is on hr/gravity/resp, which carry one sample per second and so have no ties for stability to preserve.

One thing I did and then undid: I generalised the helper behind a TimestampedBeat protocol so RrBeat could share it. Dropped that — ResonanceEngine.swift imports only Foundation and documents itself as "PURE + DB-free... decoupled from the storage entities", so a module dependency for one comparator would break that deliberately. It carries its own three-line version with a note to keep them in step.

Also worth recording, since it is not a defect: HRVAnalyzer.analyze does no defensive sort at all on either platform — it trusts caller order. That is identical across the twins and pre-existing, and it is now correct because the read is correct. Left alone rather than changed silently.

9/9 green.