Introduction

The language

At the core of Trainerflow lies a language with which one can express athletic programming of arbitrary complexity. We call this language the Coach Programming Language (Coach for short) and it is designed around a trainer–athlete feedback model.

The purpose of Coach is to let trainers, of any kind, easily design, extend and test programs that athletes can then run. A program written in Coach is not a spreadsheet of sets and reps. It is closer to the trainer standing next to the athlete: it says what to do, listens to how it went and decides what comes next.

30,000ft view

When a Coach program runs, it outputs a specification of what the athlete is supposed to do, together with what (if anything) the athlete is supposed to report back once they have done it. This feedback then returns to the program as input, and the program continues to output the next specification, and so on. The process goes on until the program has no specifications left to generate.

          ┌──────────── specification ────────────┐
          │      "5 reps of Back Squat at 80 kg"  ▼
   ┌─────────────┐                          ┌────────────┐
   │   program   │                          │  athlete   │
   └─────────────┘                          └────────────┘
          ▲      "did 4 reps"                     │
          └────────────── feedback ───────────────┘

Every time the program hands the athlete a specification it stops and waits. We call each of those stops a halt. The athlete sees the halt on their phone, does the work, enters what happened and continues, and the program picks up exactly where it left off, now knowing how the set went.

Do not worry if any of the above sounds strange right now; the picture will clear up as you read more about the specifics.

A closer look

While designing Coach we ended up with a minimal set of abstractions that you may think of as the core elements of a Coach program. These are:

• Action is something that can be performed, e.g. BackSquat.
• Input is something that can be measured, e.g. reps or duration.
• Output is something that can be specified, e.g. weight.
• Exec is a named collection of specified outputs and measured inputs that, when called, produces one of the specifications we mentioned above, e.g. squat.
• Group gathers several commands together under a name, so that calling it runs them all, e.g. day_a or week_1.

The above do nothing by themselves because they are mere definitions. For the program to do anything meaningful you have to issue one or more commands:

• Specify attaches a value to an output of an action, as part of the specification.
• Measure asks the athlete to report an input once they are done.
• Ask asks the athlete for a single measurement, right away.
• If runs commands only when a condition is met.
• Repeat runs commands a given number of times.
• While runs commands for as long as a condition is met.

Not every command interacts with the athlete. To get a more concrete picture of what these commands are about, it is worth reading the dedicated page of each one. But first, let’s write a simple program to get you started.

The rest of Trainerflow

The language is only half of the story. Around it sits the app where programs are written and run:

• The SPDK, the editor in which you write a program, with a simulator that runs it as you type.
• Running a program: activating it, following it day by day on the mobile app and changing it while it runs.
• Trainers and trainees, for trainers who program for other people.
• The AI assistant in the editor, and your own AI agent connected to your account.

If you would rather start from the words we use throughout these pages, the concepts page explains each of them.