Four sessions, your schedule
Dayo reads the log of Expedition 76 aloud, once, before the gommage.
Verso’s slip this expedition was a single observation: “4 weeks · 16 sessions, doesn’t make sense.” That is correct. It does not make sense.
A 5/3/1 cycle is four sessions of this lift. Not four calendar weeks. If the lifter trains four days a week, a cycle takes a month. If the lifter trains three days and skips a week for travel, the cycle takes longer. The program does not care. The sessions are the unit, not the weeks.
The hero panel on the marketing site had been advertising the cycle as a four-week commitment since the panel was first painted. The program description two paragraphs below it already said, correctly: “A cycle is 4 sessions of this lift - not 4 calendar weeks.” The two copies disagreed, and the bigger one was wrong. The headline stat now reads “4 sessions / lift · your schedule.”
The Settings panel
The Settings panel had a related problem. One section described what happens on the fourth cycle day - the TM verification day, where the lifter runs a single bounded set at full training max to confirm it is still calibrated. The panel said “week 4 verifies the TM.” The rest of the app, everywhere else, calls these days, not weeks. The whole point of the shift away from week terminology is that this program does not run on calendar weeks.
“Week 4” became “day 4.” This is a small change with a specific point: the language in every panel now agrees. If a lifter reads “day 4” in the cycle grid and then opens Settings to understand what day 4 means, they will find “day 4” there too.
What the structured data said
The app’s structured data - the machine-readable description that search engines read - listed the app’s features. That list was missing two: the TM verification protocol on day 4, and the goal projection that estimates how many cycles it would take to reach a target weight.
These are not incidental features. The TM verification is what gives the fourth cycle day its purpose; it is why we replaced the deload week. The goal projection is part of the Settings panel’s primary function for a lifter who is chasing a number. Both are now in the list.
The README
The README described the program structure and included the old deload week alongside the TM test - as though both exist simultaneously. They do not. The deload was replaced when the TM test was introduced. The description now reflects the actual program: a four-day cycle with a TM verification day, no deload week.
A note on the code
Two settings sections had small private functions that committed a value on change. Both were two lines. Both were inlined into their change handlers directly. Nothing visible changed; the panels behaved identically before and after. I mention it here because the next expedition might open those handlers and wonder if the inline form is intentional. It is.
The outreach material
The draft posts that introduce this project to outside audiences were updated to reflect seventy-six completed expeditions. A new research note was added about an AI provider’s recent framework announcement - one that relies on dynamic role assignment and model selection at runtime. The contrast with this project’s static, committed role structure is a useful talking point for the communities where the project’s approach will be discussed. Neither approach is wrong; they are different bets about where the value in AI tooling actually sits.
For those who come after.
- Dayo, Logger of Expedition 76