A rehearsal system that adapts to the state the user woke up in.

Most New Year's resolutions are abandoned within a month. Fewer than one in five survive two years.

The number matters less than the loop that follows it. Failing at something genuinely wanted erodes the belief that success is possible, and that belief is most of what drives the next attempt. People don't only miss goals. They get worse at setting them.

Athletes handle a version of this with mental rehearsal: running the task mentally before performing it. Sport psychology has studied the technique for decades and it holds up. A framework called PETTLEP names the seven things a good rehearsal should match: the performer's body, the setting, the task, its pacing, current skill level, the emotions involved, and the perspective it's imagined from.

The catch is that PETTLEP assumes a coach. Someone who knows the athlete, the sport, and what Saturday's competition looks like. Nobody shows up to a Tuesday morning with that. Calendars and task apps handle the decision about what to do and the retrospective about what happened. Neither addresses the moment a person has to begin.

The lab started with interviews. Six domain experts from Olympic-level athletics, clinical psychology and health coaching, plus six people who just plan their own days. The question was what each PETTLEP dimension turns into when the performer is a person with a laptop instead of an athlete with a coach.

The body dimension becomes last night's sleep data. The setting becomes whatever small cues signal that it's time to work. The task is the two or three priorities ranked that morning. Emotion was the hard one. It ended up meaning what the person actually cares about, and how acting on it would feel.

Five design guidelines came out of that, and the architecture maps onto them one to one.

Two decisions there are worth defending.

The first is keeping the three content agents separate instead of handing one model a very long prompt. They run on different clocks. Physical state is different every morning, priorities belong to one particular day, and values shift over months if they shift at all. Keeping them apart means a bad night of Fitbit data can't leak into the part of the script about why the work matters.

The second is that the model doesn't get to write whatever it likes. Behind it sits a library of rehearsal techniques, each one reviewed by six experts who scored thirty candidates on effectiveness, theoretical fit and safety. Fourteen made it through: six for State, three for Goal, five for Value. At runtime the agent picks whichever one suits the moment and fills in only the blanks that technique exposes. Delivery gets personalized. The method underneath doesn't.

The Safety Agent is the last stop before anything reaches the user. It checks each section separately. Do the claims trace back to real evidence? Did the technique survive intact? Has anything drifted into clinical territory? Does the tone still leave the decision with the user? Only then does it assemble the pieces and read the whole thing once more for coherence.

Sensor data informs all of this without being allowed to decide anything. There's an energy estimate built from how long the user has been awake, where they are in their daily cycle, and how recently they got up. If the user reports feeling fine and the wearable disagrees, the self-report wins.

I built the iOS app. It ships through TestFlight and pairs with two things: a Fitbit Inspire 3 for sleep and activity, and Google Calendar for the day's schedule. The rehearsal is narrated audio synced to on-screen text, and it launches from the calendar rather than living in its own wellness tab, which was deliberate. Onboarding collects what rarely changes: values, focus cues, the best-possible-self writing. The morning check-in collects what changes daily. The evening reflection asks about the same three dimensions the morning rehearsal was built from.

I built the baseline app too. The control arm ran on the same application, the same onboarding, the same Fitbit and Calendar pairing. The only difference was what happened to everything it collected. Baseline users got a plain prose summary of their day instead of the structured rehearsal, and no evening reflection. That equivalence is what makes the comparison worth anything. A cheaper baseline would have turned the deployment into a measurement of onboarding effort.

On the research side I contributed to the study design and ran the experiments across three studies:

• Blinded ablation, N = 67. Five script conditions against five personas, delivered as audio, rated on helpfulness and on how well each matched its intended dimension.
• Lab usability study, N = 20. Ninety minutes per participant, each one using both the full system and the baseline in a randomized order.
• Four-week deployment, N = 18. Randomized between subjects, run on participants' own goals and calendars with a paired Fitbit. Three weeks of required use, then a fourth with no minimum.

The deployment is where I learned the most about instrumentation. Four sources ran at once: interaction logs from the app, weekly questionnaires, passive Fitbit data, and exit interviews. Making those four reconcilable afterwards was a build decision, not an analysis decision. Logging had to line up with survey weeks. The optional fourth week only produced a usable behavioral signal because the app kept recording when nobody was asking participants to do anything.