Source notes
Bodiivo
How this project works, the decisions behind it and its known limits. Ask quotes and cites these passages when it answers.
Notes reviewed 20 September 2026
Explore the projectProduct
Product
Training that responds to what you actually did, with you in control. 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.
The problem it solves
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.
The experience
The product brings together a Today view, training sessions, goal-aware planning, nutrition and evidence-backed insights across web, iPhone and Apple Watch. Candidate changes move through explicit review and approval rules. The current sustained-adaptation work includes using actual post-change observations before recommending the next adjustment.
Availability
Bodiivo is in development for iOS, Apple Watch and the web. It is not yet a public release.
Engineering
Backend and architecture
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.
Technology by responsibility
Client: React, TanStack Start, SwiftUI, watchOS. Backend: TypeScript, Supabase, PostgreSQL. Platform: HealthKit, WatchConnectivity, Governed proposal services.
Data, trust and failure behavior
HealthKit's read-permission behavior means no data and denied permission cannot be casually equated. The phone adapter requests no HealthKit write types; watch workout behavior is a separate surface. Mobility doses live in a per-user preferences map updated by read-modify-write, so a lost concurrent update is not ruled out. User-owned records and governed executors remain the authoritative writers, with imported and fixture data distinguished from actual user evidence.
Governed adaptation
Conservative defaults require asking or confirmation. Goal-phase, nutrition-target and whole-program rebuild capabilities cannot be silently promoted to automatic changes.
Resolve conflicting proposals
Arbitration checks contradictory changes, tensions between goals and the number of changes already being measured. Lower-priority changes can wait with an explicit reason.
Use actual drill evidence
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.
Read health data carefully
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.
Decisions
Giving adaptive software bounded authority
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.
Measuring the result of a change
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.
Limits
Known limits
Bodiivo is not a medical device and makes no proven health-outcome claim. Injury prediction, video form correction, fully calibrated physiology and every proposed adaptation loop are not presented as finished.
Questions Ask answers from here
Can Bodiivo silently rewrite a training plan?
The policy requires explicit confirmation for rebuilding a program and prevents that capability from being set to automatic.
What happens when recommendations conflict?
A deterministic arbitration stage considers direct contradictions, goal priorities and the number of active changes before the autonomy gate runs.
Does missing health data mean permission was refused?
No. The phone adapter explicitly distinguishes having requested authorization from knowing whether every read type is permitted.