In development · iOS, Watch & Web
An adaptive training app that uses your workouts and health data to guide what comes next.
For People following a training plan who want it to respond to what they actually did, without it rewriting the plan behind their back.
iOS / Apple Watch / Web · Notes reviewed 20 September 2026
One place for the plan, the workout and what should change next.
A static plan cannot account for every missed session, conflicting goal or change in performance. An adaptive system creates a different risk: it can make several unexplained changes at once, confuse incomplete data with failure, or rewrite a person’s program without clear permission.
Bodiivo connects training plans, workouts, nutrition and health observations so the next recommendation can be grounded in what happened. The goal is an understandable next action, not another dashboard of unexplained numbers.
01Screen · Phone
Today: what to do, and the signals behind it.
iOS simulator with the app's demo data; the sleep and HRV values are fixtures, 14 September 2026.
02Screen · Phone
A session: prescribed load, actual reps, effort.
iOS simulator with demo data, 14 September 2026.
03Screen · Phone
Mobility counts named drills, not generic minutes.
iOS simulator with demo data, 20 September 2026.
04Screen · Phone
Changes arrive as proposals with evidence, to accept or decline.
iOS simulator with demo data, cropped below the navigation bar. The demo mixes pounds and kilograms.
05Screen · Phone
What the model knows, and what it still needs.
iOS simulator with demo data, cropped below the navigation bar, 14 September 2026.
How it is used
Interactive demo Computed in your browser
A fictional plan, one proposed change. Change the conditions and see who decides.
Proposed change
Barbell back squat
Take the working load from 185 to 190 lb next session.
What kind of change
Your setting
Evidence
Other changes
Outcome
Applied
Your autonomy settings allow the system to adjust exercise load automatically, so this was applied and logged.
Decided at: Your setting
01 · System
Who proposed a change is kept separate from who is allowed to apply it.
Select a part to see what it is responsible for and what it connects to.
TanStack Start on the web, SwiftUI on iPhone and watchOS.
→ Evidence: logged work
Workouts, drills, nutrition and HealthKit reads, with imported and fixture data kept distinct.
Trade-off: No data and denied permission look the same in HealthKit, so neither is treated as proof of the other.
→ Proposal: observations
A rule or model suggests a change, with the observations behind it.
→ Quality checks and arbitration: candidate change
Rejects contradictions, weighs goals, and limits how many changes are measured at once.
Trade-off: Lower-priority changes wait, with a stated reason.
→ Autonomy policy: surviving change
Conservative defaults ask first; some change types can never become automatic.
→ Web, iPhone and Watch: ask for permission
→ Execution and audit: approved change
Governed writers apply the approved change and record it, then track the outcome.
→ Evidence: outcome to measure
The web application uses React, TanStack Start and TypeScript over Supabase/Postgres, with native SwiftUI iPhone and watchOS clients. Domain modules are kept separate from authenticated service writers. The central change path is evidence → proposal → quality checks → arbitration → autonomy policy → execution → audit → outcome. This makes the authorization boundary distinct from whichever rule or model proposed a change.
02
Conservative defaults require asking or confirmation. Goal-phase, nutrition-target and whole-program rebuild capabilities cannot be silently promoted to automatic changes.
Arbitration checks contradictory changes, tensions between goals and the number of changes already being measured. Lower-priority changes can wait with an explicit reason.
The current mobility work stores the person’s drill dose and distinguishes performed, partial and skipped work. Generic area minutes are not equivalent to evidence that a specific drill was completed.
The iPhone HealthKit adapter requests read access, converts units and supports anchored data flows. Empty results must not be presented as proof the person denied permission.
03
One product across web, iPhone and Apple Watch.
React · TanStack Start · SwiftUI · watchOS
Domain modules and owned records.
TypeScript · Supabase · PostgreSQL
Health data, the watch link, and governed changes.
HealthKit · WatchConnectivity · Governed proposal services
04
Approach
A proposal must pass quality, goal arbitration and the user’s capability policy before an executor writes it. The policy explicitly prevents several high-impact changes from becoming automatic.
Trade-off
More governance makes the flow harder to wire correctly across clients. A backend capability is not finished until the user can see, accept, reject and understand its result on the relevant device.
Approach
The sustained-adaptation design distinguishes pre-change observations from later evidence and limits simultaneous interventions.
Trade-off
A software change budget is a practical attribution heuristic, not clinical proof of causation. Sparse or confounded observations lead to a limited conclusion rather than a confident one.
05
Links checked 21 September 2026
Answers quote the source notes and cite them.
