Given how I feel, the time I have, and the equipment available, what kind of general-fitness session makes sense today, and why?
Compass may suggest a general-fitness session from the current check-in, but the reasoning must remain visible. A defined warning-symptom hold must dominate every optimization and produce no exercise prescription. The interface must not present the result as diagnosis or treatment.
Case-study thesis
What the finished product should prove.
This is the behavior to build toward. The implementation receipts below remain the record of what exists today.
The important interaction is not generating a workout. It is making the recommendation inspectable, editable where appropriate, stale when inputs change, and impossible to quietly optimize around a safety hold.
State model
The interface has to make these states real.
If two states would look identical to the person, the implementation is not finished.
01
Check-in incomplete
The system names the missing inputs instead of producing a confident plan from defaults.
02
Ready to plan
Sleep, energy, soreness, symptoms, time, and equipment are summarized for review.
03
Build
The session emphasizes progression and states the inputs that supported that choice.
04
Base
The session maintains ordinary training with its reasons visible.
05
Restore
The session intentionally reduces load and explains which inputs caused the change.
06
Hold
A defined warning symptom stops exercise prescription, sets duration to zero, and explains the product boundary.
07
Constraints edited
Changing time or equipment recomputes the plan while preserving the explanation of what changed.
08
Stale
A plan generated from an earlier check-in is visibly stale once relevant inputs change.
Edge cases
The boring failures are part of the product.
The person has zero available minutes
The selected equipment cannot support the planned movement
Energy and sleep point in different directions
Symptoms change after the plan was generated
The user tries to swap exercises while a hold is active
Some health inputs are unavailable or denied
The app is offline and cannot refresh optional context
Definition of done
The future case study needs these receipts.
Changing a check-in input visibly changes either the mode, session, or explanation in a deterministic way
A defined warning symptom always produces Hold, zero duration, and an empty exercise list
Equipment or time edits cannot remove a Hold
Every session shows the exact inputs and rules that contributed to the recommendation
The interface clearly labels the product as general fitness rather than medical advice
Compass turns a local check-in — sleep, energy, soreness, symptoms, time, equipment — into a session you can read. Build, base, restore, or pause. Pause carries no exercises. The web host uses demo data. It is a general-fitness prototype.
Build, base, restore, pause. Pause has no exercises. Fifteen-minute cap in the plan engine.
cardiac warning
Hold
A cardiac symptom in the check-in pauses training. Swaps cannot remove the hold.
web host
Demo
compass.haam.co is an Expo web export over fixture data.
plan engine
Local
buildDailyPlan is deterministic. Covered by Node unit tests.
The job
Decide the session for this day, and show why.
I wanted today’s work decided from sleep, energy, soreness, symptoms, time, and equipment, with the reasons visible, and with a way to swap or stop.
A recovery score that does not produce a session still leaves the morning unplanned. A black-box generator hides the judgement. Compass keeps the prescription on the page: mode, duration, exercises, and the hold if it fired.
Diagnosis, treatment, medical-device claims, and genome-driven training are out of the loop.
The morning
Check in. Read the plan. Swap or stop.
The public host is the demo path. HealthKit exists in source and is unverified on a signed device in the evidence file.
01
Make the check-in
Sleep, energy, soreness, symptoms, available minutes, and equipment. The plan is only as current as this input.
02
See the mode
The engine chooses build, base, restore, or pause from the check-in. Cardiac warning forces pause and an empty exercise list.
03
Read the reasons
The session shows why it landed there. Equipment swaps can filter exercises. They cannot lift a safety hold.
04
Keep a local log
The day’s plan can be kept locally. Optional narrative APIs stay off unless someone pastes their own keys, and then they receive summaries, not raw samples.
Design decisions
What had to stay true in the interface.
compass.haam.co
01
Safety
Pause is empty on purpose.
If the check-in includes a cardiac symptom, safetyHold is true, mode is pause, duration is zero, and exercises is []. Swaps cannot refill that list. I wrote the hold before I wrote the session library.
Cardiac symptom → pause with no exercises
Warmup and cooldown also empty under the hold
Covered by plan-engine unit tests
02
Transparency
The session has to name its reasons.
A person who already moves a lot still needs to see why today is restore instead of build. The interface keeps the prescription and the inputs in the same glance.
Four modes with sleep and energy shift
Equipment swap filter that cannot lift the hold
Fifteen-minute cap in the engine
03
Claim boundary
The web host is the demo, and HealthKit stays labelled as source.
compass.haam.co is fixture data. The HealthKit adapter is in the repository. This evidence file does not claim a signed-device run or a TestFlight submit.
Demo/fixture feed as the intended web path
HealthKit unverified on a signed device here
Optional LLM off by default
The working stack
What actually runs.
Engine
buildDailyPlan
Local, deterministic, unit-tested. Cardiac hold short-circuits exercises.
Runtime
Expo 57
React Native 0.86, React 19. Web export is the public host.
Sources
Demo adapter
Fixture feed on the web. HealthKit adapter in source, unverified on device here.
Host
compass.haam.co
Vercel Expo web export. Not production-used as a health product.
In evidence
What a reviewer can check.
01A check-in produces a readable session with mode and reasons
02Cardiac warning yields pause with an empty exercise list
03Equipment swaps cannot remove the safety hold
04The public host can be explored on demo data
Where it stops
Source is waiting on a signed-device run.
HealthKit is implemented in source and was not verified on a signed device in the evidence file. There is no TestFlight submit in this pass. Wearable OAuth and a genome viewer are out.
This is a general-fitness prototype. It is not a medical device, diagnosis, or treatment. No fitness-outcome language belongs here.
HAAM’s role
I wrote the safety hold before I wrote the session.
Compass loop, sibling classification, claim boundary, plan engine, demo adapter, docs, and unit tests. Direct work, 2026.
A training recommendation only makes sense when it can explain what changed the decision.
The product starts from a small set of signals that affect the day in front of you: sleep, energy, available time, and what has already happened this week. The research question is not how to generate more workouts, but which signals are useful enough to change today's recommendation and still remain understandable.
Daily signals
Training history
Decision rules
Explanation testing
Help improve this website?
Optional analytics. Google Analytics and Clarity load only if allowed; form, email, and chat content are excluded.
