How the next training session is chosen
This is how a completed session changes the next one: the inputs, the three decisions, and the sentence the screen shows.
The only path that updates the next session
A plan exists → the person performs the session → the performance is recorded → history for those exercises updates → recovery is evaluated → the next session progresses, holds, or reduces
Opening the screen is not performing the session. A session the person did not log does not update history. The engine does not infer a workout from an opened page.
Inputs
| Input | Used for | If it is missing |
|---|---|---|
| Exercise | History is kept per exercise, not per “leg day.” | The set is not stored. |
| Sets, reps, and load | What was done. Load without a unit is invalid, same rule as a lab value without a unit. | That exercise’s history does not move. |
| History | Comparison with this person’s recent work. | The plan stays at the last prescription. It does not jump to a population default. |
| Goal | Whether progression favors load, reps, or density. | The current goal remains. The screen asks only when no goal exists. |
| Recovery | Whether the next session progresses, holds, or reduces. | The engine holds. It does not progress while recovery is unknown. |
| Cardio in a zone | A separate load on recovery. It does not rewrite strength history. | Strength decisions use strength history only. |
The three decisions
| Decision | When | What changes |
|---|---|---|
| Progress | Recorded work met the prescription, and recovery is sufficient. | The next prescription moves in the direction of the goal. |
| Hold | Work was completed, and recovery is unknown or borderline. | The next prescription matches the last one. |
| Reduce | Recovery is insufficient, even if the last session looked strong. | The next prescription is lighter, and the reason is recovery, not failure. |
A partial log stays partial. The engine does not invent a personal record from sets that were not entered. Two sessions on the same exercise on the same day both count. The second is discarded only when the set list is identical and the client retried a save.
A planned deload is not a reduction
A deload week is a plan state someone chose. A reduction is a decision the engine made because recovery was insufficient. They can produce a similar prescription and they are different objects. The screen names which one the person is in. If it does not, a practitioner cannot explain the week, and the person will treat the engine as arbitrary.
Units
Pounds stored as kilograms are a validation error. The history is not repaired by a silent conversion. This is the same rule as the observation contract: the stored row matches what was submitted. A conversion, if we add one, is its own operation and its own row.
What the screen has to show
The next-session screen shows the prescription and a reason code: progressed, held, or reduced. For a reduction or a hold, it shows the input that decided it. “Recovery unknown” and “recovery insufficient” are different sentences. A person who logs a hard session and then sees a lighter day needs the recovery sentence on that screen.
The screen does not show a suggestion from the model as if it were the decision. If a model proposed the session, the application either accepted it and wrote a decision, or it did not. The screen shows the decision. See who is allowed to write.
Out of scope
- Medical clearance. The engine does not decide whether someone should train.
- Pain reports. A pain flag stops progression and asks a person. It does not diagnose.
- Replacing a coach. The reason codes exist so a coach can disagree with the decision in the open.