Atriveo Bio Apple Watch data in, one readiness score out. With every reason behind it listed.

An iPhone app syncs HealthKit data to an API that builds a personal feature store: sleep, HRV, resting heart rate and activity, each against your own 30-day baseline. From that it scores readiness, estimates your chronotype and forecasts the day's best deep-work window.

Stack
TypeScript · Hono · Postgres · Prisma · SwiftUI · HealthKit · XGBoost
Status
Live, public beta, since June 2026 · bio.atriveo.com ↗︎ · GitHub ↗︎
  • 6layers, samples to forecasts
  • 3baselines a model must beat
  • 30-daypersonal baselines

Atriveo Bio

TypeScript · Hono · PostgresOpen site
Atriveo Bio's landing page split into floating layers: navigation, “Know when you'll perform at your best”, and the readiness card

01 · Problem

Wearables report numbers, not what to do.

An Apple Watch records sleep, heart-rate variability, resting heart rate and steps, but raw numbers don't say whether today is a day for deep work, or when in the day to do it.

02 · Solution

Compare you with you, then explain the score.

Samples land append-only, roll up into daily and hourly features, and are compared with 30-day personal baselines. Readiness is a rules-based score that returns its reasons, such as “Strong sleep +12” or “Short sleep −15”.

03 · Engineering

Each sync recomputes features for the days it touched. Sleep uses the night's longest session, so naps don't count twice.

04 · Key decisions

  • Explainability before ML: rules first
  • Append-only raw samples, always recomputable
  • Baseline-gated models: beat yesterday first
  • Re-sync safe: samples de-duplicated
  • Open engine (MIT), hosted API separate

Engineering note

Machine learning had to earn its place. Every model is scored against yesterday, a 7-day average and the rules.

The training script fits XGBoost on sleep, HRV, activity, chronotype and weekday, then records whether it beat all three baselines. Until a model does, the explainable rules-based score stays the default.