Idea
Send the morning readiness briefing only after fresh HealthKit recovery data has been synced and processed, instead of relying only on a fixed 10:00 schedule.
Problem
The current morning briefing is sent at a fixed time, usually 10:00.
At that moment HealthKit data from the previous night is often not synced yet, because the iOS app may not have opened or background sync may not have run.
As a result, the briefing can be based on stale data and may miss:
- last night's sleep
- morning HRV
- resting heart rate
- updated recovery score
- updated readiness score
This makes the recommendation less trustworthy.
Proposed solution
Introduce freshness-aware, event-driven morning briefing logic.
Preferred flow:
- iOS HealthKit sync completes
- backend ingests and processes HealthKit data
- backend recomputes recovery/readiness for today
- if this is the first successful fresh sync for the current day
- send morning readiness briefing
Data freshness rules
A morning briefing should distinguish:
Do not present stale readiness as fully reliable.
Fallback behavior
If no fresh HealthKit sync happens by a configurable fallback time:
- send degraded/fallback briefing, or
- notify that HealthKit data is stale
Requirements
- morning briefing should be sent once per day
- fresh sync should trigger the briefing
- fixed schedule becomes fallback-only
- briefing includes data freshness indicators
- duplicate briefings must be prevented
- backend owns freshness logic
Suggested implementation
Track:
- last successful HealthKit sync timestamp
- latest recovery data timestamp
- daily briefing sent flag
- freshness state
Possible trigger points:
- HealthKit sync completion
- recovery recomputation completion
Acceptance criteria
- fresh sync triggers morning briefing
- repeated syncs do not duplicate briefings
- stale data is clearly marked
- fallback exists when sync is missing
- tests cover freshness/fallback scenarios
- readiness message includes freshness metadata
Out of scope
- full iOS background sync implementation
- push notification infrastructure
- ML recommendation changes
Value
High.
Prevents readiness recommendations from being generated using stale physiological recovery data.
Idea
Send the morning readiness briefing only after fresh HealthKit recovery data has been synced and processed, instead of relying only on a fixed 10:00 schedule.
Problem
The current morning briefing is sent at a fixed time, usually 10:00.
At that moment HealthKit data from the previous night is often not synced yet, because the iOS app may not have opened or background sync may not have run.
As a result, the briefing can be based on stale data and may miss:
This makes the recommendation less trustworthy.
Proposed solution
Introduce freshness-aware, event-driven morning briefing logic.
Preferred flow:
Data freshness rules
A morning briefing should distinguish:
Do not present stale readiness as fully reliable.
Fallback behavior
If no fresh HealthKit sync happens by a configurable fallback time:
Requirements
Suggested implementation
Track:
Possible trigger points:
Acceptance criteria
Out of scope
Value
High.
Prevents readiness recommendations from being generated using stale physiological recovery data.