Why a New Sleep Session Shouldn’t Replace Last Night

A day can contain the end of one night and the beginning of the next. That makes “show today's sleep” a more interesting query than it first appears.

In the October work on Boop, now Every Band, a pending evening sleep session could displace an earlier completed main night on the same waking date. The newer session existed, but it was not yet the useful answer to the question the day view was asking.

The correction was about choosing the right record before calculating anything from it.

Historical Boop Sleep fixture with illustrative data from the existing archive. It shows the main-sleep and tonight sections. It is not a screenshot of the October fix or a fresh capture of the current App Store build.

Choosing the completed main night

A database can return the most recent session. The interface needs a session with the right role: the completed main night associated with the day being viewed.

Those answers agree often enough to make the shortcut tempting. They separate when a new session is still pending. Replacing the previous night at that point can make a stable daily view change because a different operation has started, rather than because better evidence about that night has arrived.

The October candidate protects the completed main night from that pending evening session. It keeps the distinction between a record being newer and a record being ready to represent the night's result.

The pending and completed states therefore need to remain part of the selection rule, rather than disappear after sorting sessions by time.

Fix the inputs before tuning the score

The same candidate addressed two quieter input issues.

A finite negative local temperature deviation needed to remain valid. A negative deviation is a signed difference, not automatically a missing value. Rejecting it simply for falling below zero would change what the stored input means.

Sleeping heart rate also needed to reflect covered time. When observations cover unequal intervals, giving each observation the same weight answers a different question from weighting the time each one represents.

These corrections concern selection and aggregation. The recorded change kept the Recovery formula and its weights unchanged. It did not establish a new clinical model or a gain in measurement accuracy.

That distinction helps keep the investigation focused. A strange result can come from the wrong night or a mishandled input before it comes from the formula that combines those inputs.

A correction also has a history problem

Changing the derivation logic is only part of the work when the app already holds results produced by an earlier version.

The candidate included a derivation-state upgrade that requested the existing bounded rebuild of retained history once. It preserved profile and legacy state rather than treating the fix as a reason to start the person's history over.

A bounded rebuild also has a limited claim. It operates on the history the app has retained. It does not prove that every missing day can be recovered or that every possible record has passed an independent preservation audit.

Keep the acceptance result specific

The engineering record binds the change to commit 3750957 and TestFlight 2.1.18 build 118. That build's internal and external TestFlight availability was verified on 18 October. The record also reports selected package tests and source-bound simulator checks.

Those are historical acceptance facts. They do not establish Full-score device acceptance, clinical accuracy, vendor parity, or complete overnight reliability. This is an account of that fix, not a claim that a later private candidate has been released publicly.

The repair gives the day view a consistent starting point: the completed main night associated with the selected day. A new evening session can remain in progress without replacing that record. The score and the explanation beside it can then refer to the same selected night.