Letting AI In Without Handing Over the Plan
openGym treats AI as an optional boundary crossing, not as a hidden requirement of the tracker. This chapter compares the AI Coach with the read-only MCP bridge, then follows a Coach proposal from consent to validation and possible application. The practical question is not whether a model can suggest a routine. It is whether openGym can let an external model interpret selected training data without silently receiving the whole profile or acquiring authority over the historical record.
Two Integrations, Two Trust Decisions
The AI Coach is off until an administrator configures a provider and enables it. A signed-in person must also consent before a job is queued. That sequence makes the Coach different from an ambient assistant that can inspect the account whenever a screen opens. The administrator chooses the provider and account arrangement; the person agrees that the Coach may use the listed categories of their data; the job then runs within those decisions.
The data contract is deliberately narrower than the profile itself. The Coach may receive the plan, selected training history, body-weight information, intake answers, and a few preferences. An optional comparison feature can add coarse cohort information when both the administrator and the person have opted in. The payload uses a stable pseudonym rather than the profile’s user id. Credentials, passkeys, display identity, push subscriptions, invite information, appearance settings, and other profiles are excluded. A review is bounded to a training window rather than sending an unlimited career history, and a debrief focuses on a particular workout and limited context.
The consent screen and the payload builder are tied to the same category list. That coupling matters because a consent screen that is maintained separately from the code that sends data can drift. It might promise that one category is excluded while a later state field is spread into the request accidentally. The allowlist instead copies fields by name. A new field added to the profile state does not automatically travel to a provider just because it exists in the object.
The provider account is part of the trust decision as well. An instance-level API key may be shared across profiles, subject to configured limits. A personal credential can bind to the first profile that spends it, with other profiles refused rather than merely warned. That distinction protects a person’s subscription or personal account from being treated like an unowned household resource. The technical question “which model should run?” cannot be separated from “whose account pays, who consented, and who is allowed to use it?”
The MCP bridge has a different shape. It is a local stdio process spawned by an external LLM client and reads selected profile files directly from the same host. It makes no network call, adds no container, and is read-only. It exposes queries over routines, effective sessions, workouts, body weight, estimated 1RM, and muscle balance, using the same pure training helpers as the main UI so that the numbers should agree with what openGym displays. The filesystem is its trust boundary: the local LLM client can read what the bridge exposes, but the bridge does not receive passkeys, VAPID keys, or session secrets.
Read-only interpretation is materially different from a provider that proposes changes.