Why the Training Log Must Remain Editable

openGym’s progression loop depends on a distinction that is easy to overlook: a live workout is an interaction, but a completed workout is historical evidence. This chapter follows that evidence from the moment a session is running through completion, later correction, and the derived views that interpret it. The practical judgment is simple but important: an editable log does not weaken consistency when recommendations are derived from history; it is what allows the application to correct the record without rewriting the past.

From Live Rows to a Corrected Record

A live workout contains more than the facts that should survive. It may hold a planned duration temporarily displaced by an edit, a weight inherited from a previous row, an unchecked set, a current timer, or other bookkeeping needed to make the screen responsive. Those fields help the person finish the session, but they are not all historical facts. openGym’s completion boundary removes live-only information and keeps what was actually logged, along with the target, routine context, planned values, exclusions, notes, and records that later readers need.

That boundary protects two different kinds of truth. The first is event truth: what the person did on a particular day. The second is interpretation: what the application concludes about that event, such as whether it met a target or should influence the next load. A completed workout can contain the target that was shown at the time, but it does not need to store a permanent progression counter saying how many successes have occurred since then. The next prescription can read the event again.

This matters when a person corrects a saved workout. A mistyped weight, an omitted set, or an incorrect date can affect the meaning of later sessions. If the application treated every previous calculation as permanent, the user would have to repair a chain of derived counters in addition to fixing the original mistake. openGym instead keeps the workout as the durable record and re-reads it through the same history and progression helpers. The corrected event can change the next prescription and the progress view without pretending that the original entry never existed.

The same logic applies when the routine changes. A workout built from one plan should not be judged as if it had been built from a later plan. openGym keeps the planned values used to construct the session separate from the target that progression moved. When a later reader sees that the routine’s sets or reps have changed, it can treat the old session as evidence about the old target rather than as a miss against the new one. The result is not that every edit erases consequences. It is that consequences are recalculated from the right premise.

Routine-specific history adds another layer. The same exercise may appear in a heavy routine and a lighter routine, or in two sessions combined on one day. Treating every occurrence as one line of progression would cause a success in one context to move the target in another. openGym associates saved entries with their originating routine when that information exists. The routine’s own history is preferred; broader exercise history can establish a starting point when the routine has not yet trained the movement. This lets a copied routine begin from something the person actually lifts without collapsing distinct program contexts into one stream.

Exclusions matter for the same reason.