methodology

the architecture of accountability

Most fitness software is designed for one person, the coach or the athlete, and passes information across a gap between them. We built Trainbase the other way: one system with two interfaces over a single shared data model. Mutual accountability is not a feature we added. It is what a system shaped this way does on its own.

the flaw in single-sided systems

Conventional platforms sit in one of two camps, and both leave the same gap. A consumer tracker is a data repository for one person with no link to guidance. Coaching software treats the athlete as a profile that receives programs and reports back. Either way information flows one direction across a seam, and accountability becomes a manual habit of chasing check-ins on top of a disconnected system.

single-sided systemshared data model
goal settingthe coach issues a directivean agreement on one shared goal object
progress visibilitya report sent after the factthe program itself changes, in view of both
check-ina separate scheduled workflowevery interaction is already a check-in
accountabilitya feature layered on topan emergent property of the structure

a shared reality, one object at a time

A workout, a nutritional target, a progress reading: each is not a copy in the coach's database and another in the athlete's app. It is one object in one database that both parties can see and, in controlled ways, change. That single sentence is the whole methodology. Everything below is what follows from it.

one shared goal object
coach interfaceproposes a targetwrites once to the shared object
athlete interfaceaccepts the targetreads and agrees to the same object
proposedactive

A goal is not imposed. It moves from proposed to active only when the athlete agrees, so the data itself records the pact both parties are now accountable to.

Versioned by effective date, so the history of what was agreed is never overwritten. The coach proposes; the goal drives nothing until the athlete accepts it, and the same object flips to active. This is shipped behaviour, enforced in the database itself.

progress that points both ways

When an athlete logs a set or a meal, they are not filing a record for themselves. They are updating the state of a shared object, and the coach sees the program change, not a separate report about it. The data stream is constant and runs in both directions, so there is no ambiguity left for a check-in to resolve. The coach is accountable for a program that works; the athlete is accountable for executing it; the system holds both to the same record.

1shared data modelnot two apps exchanging copies
2interfaces over itcoach and athlete, one reality
both waysthe data streamevery log updates a shared object
0separate check-in stepevery interaction is the check-in

See how the pieces fit together on the platform.

accountability as an emergent property

Shaped this way, accountability stops being something to build. There is no separate check-in function because every interaction already is one. The loop is not a workflow we layered on; it is the only way the system can operate. That is the difference between connecting two people with messages and giving them one shared space where their goals, actions, and progress are intertwined by design.

the honest answers

Is mutual accountability a feature I turn on?

No. It is a property of how the data is shaped, not a setting. Because a workout, a target, and a reading are single shared objects rather than copies passed between two apps, the coach and the athlete are always looking at the same reality. There is no accountability switch because there is no version of the system without it.

How is this different from a coaching app that sends programs to a client app?

Those are two applications that exchange messages. A program lives in the coach's database and its execution lives in a separate client-owned space, so the connection is fragile and always one step behind. Trainbase is a single system with two interfaces over one data model: when an athlete logs a set, the coach sees the program itself change, not a report about it.

Does the goal flow already work the way you describe?

Yes. A coach writes a goal and it is saved as proposed. It changes nothing on the athlete's targets until the athlete accepts it, which flips the same object to active. Goals are also versioned by effective date, so the history of what was agreed is never overwritten. If a coach revises a proposed goal, the agreement resets and the athlete accepts the new terms.

The full argument, in Eugene's words, is in the architecture of accountability.

one system. two interfaces. one shared truth.

See the architecture working across training, nutrition, and body metrics, or step straight in and put your roster on it.