The First Operating Model: Ownership Across Data and Behavior
The earlier parts of this series established three facts about openGym: a profile can be held by a person or operator rather than a hosted vendor, a routine becomes a workout through explicit progression rules, and the completed log remains editable evidence for later calculations. This checkpoint connects those facts into one operating model. Its practical purpose is to let a reader look at any user action and ask what should be preserved, what should be recomputed, and what must remain local when the same profile exists on more than one device.
An Owned Profile Is More Than a File
The smallest useful model of openGym has three layers. The first is an owned profile: routines, weekly intent, settings, workouts, weigh-ins, and the user’s other durable records. The second is a training history: the completed events that say what happened, under which plan and exercise context. The third is derived behavior: the next session’s prescription, estimated strength, recovery view, and other interpretations produced from the stored record.
Those layers are connected but not interchangeable. A routine can influence a session without proving that the session occurred. A completed workout can influence a next target without being rewritten into that target. A recovery display can summarize recent training without becoming a new workout event. This is the central model behind openGym’s ownership claim: the user’s durable record remains the thing from which behavior is derived, rather than a remote service’s hidden counters becoming the only explanation for what the application does next.
The deployment architecture supplies the physical side of the same model. The profile document is stored by the API on the host-controlled filesystem. The browser or phone holds the interaction state needed to edit it and may hold a live workout that has not yet become a completed event. The application’s pure training logic reads the durable state to construct a prescription and later reads the completed history to interpret it. The project’s optional local or provider-backed integrations create additional views or data paths, but they do not have to become the owner of the profile itself.
This makes “ownership” a chain of relationships rather than a single location. A person owns the decision to create a routine. A device temporarily owns the active interaction. The profile state owns the completed record once it is saved. The progression and recovery logic own no independent history; they transform the record into a result. An optional external client may read a projection, but that does not grant it the authority to rewrite the source. Each boundary is meaningful because it answers a different question about the same training life.
The diagram is intentionally asymmetric. A derived view describes a profile, but it is not another independent history. A workout can reference media without embedding the bytes inside the profile document. A routine shapes a workout, but the workout remains the record of what was actually done. These distinctions prevent a common failure in application design: copying every value into every layer until no one can tell which copy is authoritative.
The model also explains why openGym can support both a small self-hosted deployment and a local phone mode without making them identical. In server-backed mode, the profile document is the shared durable home. In local phone mode, the phone’s private file plays that role.