How MyNextRow Reads Your Logbook to Choose a Workout: A Research-Grade Synthesis

Abstract

When a rower asks MyNextRow's coach for a workout, the coach runs a fixed pipeline of decisions on a small, sparse, evolving set of signals: the rower's Concept2 Logbook history pulled via the documented OAuth API ([1] Concept2 Logbook API docs, Level 5), the onboarding goal they selected at sign-up (race, fitness, recovery, or technique), and any preferences they have shared in chat ([2] Foster 2001, Level 5; [3] Halson 2014, Level 5; [7] Bourdon et al. 2017, Level 5). The session it returns is the synthesis of those signals — not a fixed plan matched to a key ([12] Cai et al. 2019, Level 5; [16] Burke 2002, Level 5). The coach is opinionated about safety (no back-to-back hard sessions, respect an acute load ceiling, [4] Soligard et al. 2016, Level 5; [5] Gabbett 2016, Level 2b; [6] Hulin et al. 2014, Level 2b) and conservative about personalization (it will not invent goals the rower did not set, [10] Amann et al. 2020, Level 5; [11] Ghassemi et al. 2021, Level 5). It uses session-RPE × duration as the load input because the rowing-specific literature supports it over TRIMP and TSS for indoor rowing ([20] Sanders et al. 2017, Level 2b; [21] Smith et al. 1998, Level 2b). The reference-pace anchor comes from a longer history, ideally a 2K time, recent bests, and recent average splits ([22] Russell et al. 1998, Level 2b; [25] Jones & Vanhatalo 2017, Level 5; [24] Ingham et al. 2007, Level 2b). The default intensity distribution inherits the polarised 80/20 framework ([28] Seiler 2010, Level 5; [29] Seiler & Kjerland 2006, Level 2b; [30] Stöggl & Sperlich 2014, Level 1b) when the goal is race, the ACSM weekly-dose targets ([31] Garber et al. 2011, Level 5; [32] MacInnis & Gibala 2016, Level 5) when the goal is fitness, and an autonomic-recovery-aware easy-day emphasis ([35] Seiler et al. 2007, Level 2b; [36] Kellmann et al. 2018, Level 5) when the goal is recovery. The signals the dashboard cannot infer silently — sleep, soreness, life stress — are inputs the rower brings back to the coach through chat ([3] Halson 2014, Level 5; [37] Plews et al. 2013, Level 5; [38] Saw et al. 2015, Level 1a; [56] Düking et al. 2018, Level 5). The personalization literature this design inherits — contextual bandits, hybrid recommenders, cold-start methodology, session-based recommenders — comes from recommender systems rather than from sport science ([15] Li et al. 2010, Level 5; [16] Burke 2002, Level 5; [17] Schein et al. 2002, Level 5). The transparency literature that defends the coach's "declare what was read, declare what was synthesised, declare what was not" posture comes from explainable AI in healthcare ([10] Amann et al. 2020, Level 5; [11] Ghassemi et al. 2021, Level 5; [13] Kizilcec 2016, Level 5; [14] Miller 2019, Level 5). The honest read: the coach is a small, well-instrumented recommender system with hard safety guardrails and a context vector that the rower is expected to keep current.

What the coach actually sees: three signal streams

Before going into the pipeline, it helps to state the coach's three signal streams once, without inference or philosophy.

Logbook history. The coach's primary input is the rower's Concept2 Logbook, read through the public OAuth API ([1] Concept2 Logbook API docs, Level 5). The coach pulls the last ten sessions on each request: date, distance, time, average split, stroke rate, and the rower's logged type (steady state, intervals, race, etc.). It also pulls a longer history — typically the last 90 days — used to anchor reference pace and to compute load trend metrics. The API does not expose pre-computed aggregates, so any "weekly volume," "streak," or "personal best" the coach surfaces is derived client-side from the session list. The coach does not invent Logbook sessions; if the rower has not logged in for three weeks, the coach's last-ten window has only seven entries, and the longer window is missing one of its anchors. The honest read: the coach is only as current as the Logbook sync.

Onboarding goal. When the rower signs up, they pick a primary goal from a fixed list: race, fitness, recovery, or technique. The coach treats this as the strongest single prior in the system — it does not invent goals the rower did not set ([10] Amann et al. 2020, Level 5; [12] Cai et al. 2019, Level 5). The onboarding goal sets the default intensity distribution (polarised for race, ACSM weekly dose for fitness, autonomic-recovery emphasis for recovery, technique-first work for technique), the default session structure (intervals vs steady state), and the default rest-day cadence ([28] Seiler 2010, Level 5; [29] Seiler & Kjerland 2006, Level 2b; [30] Stöggl & Sperlich 2014, Level 1b; [31] Garber et al. 2011, Level 5; [35] Seiler et al. 2007, Level 2b). The goal is not a verdict — the rower can change it, and the coach treats a chat-shared preference shift as a softer override — but until the rower says otherwise, it is the assumption.

Chat preferences. The coach's third signal stream is everything the rower has said in chat: "I have a knee issue," "I prefer steady state," "I'm tapering for a 2K on the 14th," "I slept four hours last night," "I have a head cold." These are first-class signals — not add-ons ([3] Halson 2014, Level 5; [38] Saw et al. 2015, Level 1a; [56] Düking et al. 2018, Level 5). The coach treats declared soreness, declared illness, and declared poor sleep as vetoes on hard sessions, regardless of what the dashboard says ([5] Gabbett 2016, Level 2b; [4] Soligard et al. 2016, Level 5). It treats declared preferences as soft constraints: a knee issue biases the coach toward low-impact, knee-friendly work; a steady-state preference biases it toward long, even splits; a taper date biases it toward a pre-race volume reduction ([33] Mujika & Padilla 2003, Level 2b; [34] Bosquet et al. 2007, Level 1a). The rower's stated context, when it conflicts with the dashboard, wins.

The three streams are not equal. The onboarding goal is a strong prior, the Logbook history is a strong signal, and the chat preferences are a strong override. The coach does not average them — it weights them, with safety at the top of the weight stack ([4] Soligard et al. 2016, Level 5; [5] Gabbett 2016, Level 2b; [11] Ghassemi et al. 2021, Level 5).

What the Concept2 Logbook API actually exposes

The coach's primary input is the rower's Logbook, and the Logbook's primary input is the public Concept2 Logbook API ([1] Concept2 Logbook API docs, Level 5). It helps to be precise about what the API exposes and what it does not, because the coach's modelling assumptions are bounded by the API's data surface.

Per-session fields exposed by /api/users/{user}/results. The /results list endpoint and the /results/{id} detail endpoint expose, for every logged workout, the following fields: date, timezone, type (rower / SkiErg / BikeErg / dynamic / slides / paddle), distance, time, weight class, stroke rate, heart rate (with average, min, max, ending, and recovery sub-fields), stroke count, calories total, watt-minutes total, drag factor, rest distance, rest time, the workout-type enum (JustRow, FixedDistanceSplits, FixedTimeSplits, FixedCalorie, FixedWattMinute, FixedTimeInterval, FixedDistanceInterval, FixedCalorieInterval, FixedWattMinuteInterval, VariableInterval, VariableIntervalUndefinedRest), the workout array (per-interval distance / time / stroke rate / heart rate / pace / watts / targets), and a metadata object that captures the logging client's version, the PM firmware version, the serial number, the device type, and the erg model ([1] Concept2 Logbook API docs, Level 5).

What the API does not expose. The API does not expose any pre-computed aggregate, weekly-volume total, streak, calendar view, or personal-record endpoint. There is no /aggregate, no /totals, no /calendar, no /records endpoint ([1] Concept2 Logbook API docs, Level 5). Any "this week you've rowed 32 km" the coach surfaces is computed client-side from the session list, with from / to / type / updated_after query parameters. The coach does not have a feed it can subscribe to for "current weekly total"; it has to ask, every request.

Stroke-by-stroke data. The /results/{id}/strokes endpoint exposes per-stroke records with five fields: t (time in tenths of seconds, cumulative), d (distance in decimeters, cumulative; resets to 0 at the start of each interval for interval workouts), p (pace in tenths of seconds per 500 m), spm (strokes per minute), and hr (current heart rate) ([1] Concept2 Logbook API docs, Level 5). The structured JSON stroke endpoint does not include force-curve data — that lives in the FIT or CSV export from /results/{id}/export/{type}, which the coach does not currently ingest. The coach's stroke-level model is pace + rate + heart rate; force-curve-level modelling is out of scope.

OAuth scopes. The API supports four scopes: user:read, user:write, results:read, results:write. Write scopes implicitly include read. The coach requests user:read results:read — the minimum scope required to pull the rower's profile and Logbook history ([1] Concept2 Logbook API docs, Level 5). It does not request write access. The coach never writes to the rower's Logbook.

Webhooks. The API supports registered webhook callbacks for result-added, result-updated, result-deleted events. The coach could in principle subscribe; today it polls on request.

The bottom line for the data pipeline: the coach's view of the rower is bounded by what the Logbook API exposes per session, plus the derived aggregates the coach computes client-side. The coach does not see what the API does not expose, and it is conservative about overreaching from sparse data ([17] Schein et al. 2002, Level 5; [15] Li et al. 2010, Level 5).

The data pipeline, step by step

Given the three signal streams, the coach runs a fixed pipeline. The pipeline is intentionally explicit; the design's transparency depends on each step being auditable ([13] Kizilcec 2016, Level 5; [14] Miller 2019, Level 5).

Step 1 — pull Logbook. The coach requests the last ten sessions (from = today − 14 days, type = rower, page size 50) and a longer history (from = today − 365 days, page size 250). The pagination stops when the response returns fewer than 250 entries. Sessions older than 365 days are out of scope unless the rower explicitly asks.

Step 2 — anchor reference pace. If the rower has logged a 2K time in the last 365 days, the reference pace is anchored to that 2K split ([22] Russell et al. 1998, Level 2b; [23] Mikulić & Ružić 2008, Level 2b; [24] Ingham et al. 2007, Level 2b). If multiple 2K times exist, the coach weights the most recent by default and uses the average of the last three as a smoothing input. If no 2K exists but the rower has logged a 5K, 6K, or 30-minute test, the coach projects a 2K estimate using the critical-power / critical-speed framework ([25] Jones & Vanhatalo 2017, Level 5). If the rower has no time-trial history, the coach falls back to the average split of the last ten sessions and widens its confidence band accordingly ([26] Pyne et al. 2006, Level 5; [27] Kramer et al. 1994, Level 2b). The reference pace is the anchor, not the prescription; it sets the scale on which today's targets are expressed.

Step 3 — compute load trend. From the longer history, the coach computes exponentially weighted moving averages of session load at 7-day (ATL) and 42-day (CTL) time constants, the training-stress balance (TSB = CTL − ATL), and the acute-to-chronic ratio (ACWR = ATL ÷ CTL). These are the load governors the coach weighs against context — they are not the prescription, but they are inputs to it ([2] Foster 2001, Level 5; [5] Gabbett 2016, Level 2b; [6] Hulin et al. 2014, Level 2b; [20] Sanders et al. 2017, Level 2b). The coach's per-rower trend framing follows [26] Pyne et al. (2006, Level 5) and [27] Kramer et al. (1994, Level 2b): individual athlete trends beat population thresholds.

Step 4 — read chat context. The coach reads the rower's most recent chat history for any preferences, declared soreness or illness, sleep notes, or context shifts. Anything said in chat in the last seven days is treated as live; anything older than seven days is downweighted. The chat is the place where the rower tells the coach what the dashboard cannot infer ([3] Halson 2014, Level 5; [37] Plews et al. 2013, Level 5; [38] Saw et al. 2015, Level 1a; [56] Düking et al. 2018, Level 5).

Step 5 — apply safety rules. The coach applies four safety rules in order, regardless of the rest of the pipeline ([4] Soligard et al. 2016, Level 5):

1. No back-to-back hard sessions. If the rower's last session was an interval or race-type piece, today is not another interval or race-type piece.
2. Acute-load ceiling. If the ACWR is above 1.5, today is easy or rest regardless of the calendar.
3. Declared-illness veto. If the rower has said in chat that they have a cold, flu, fever, or any acute illness, today is rest regardless of the calendar.
4. Declared-sleep veto. If the rower has said in chat that they slept under five hours, today is easy or rest regardless of the calendar.

These are non-negotiable. They are not "preferences the coach weighs" — they are guardrails the coach cannot cross ([11] Ghassemi et al. 2021, Level 5; [14] Miller 2019, Level 5).

Step 6 — synthesise today's session. Given the reference pace, the load trend, the chat context, and the safety rules, the coach synthesises a single session. The synthesis follows the onboarding goal's default intensity distribution:

• Race: polarised 80/20 default ([28] Seiler 2010, Level 5; [29] Seiler & Kjerland 2006, Level 2b; [30] Stöggl & Sperlich 2014, Level 1b), interval-heavy ([32] MacInnis & Gibala 2016, Level 5), taper-aware ([33] Mujika & Padilla 2003, Level 2b; [34] Bosquet et al. 2007, Level 1a).
• Fitness: ACSM weekly dose default ([31] Garber et al. 2011, Level 5), mix of steady state and intervals ([32] MacInnis & Gibala 2016, Level 5).
• Recovery: autonomic-recovery emphasis ([35] Seiler et al. 2007, Level 2b; [36] Kellmann et al. 2018, Level 5), sub-VT1 work, longer rests, conservative load ([39] Halson & Jeukendrup 2004, Level 5; [40] Meeusen et al. 2013, Level 5).
• Technique: drill-first, with explicit technique cues and short intervals to allow focus ([58] Concept2 — Stroke Rate, Level 5; [59] Concept2 — Drive Length, Level 5).

The synthesis is one session, not a menu. The coach does not give the rower twenty options to choose from ([13] Kizilcec 2016, Level 5; [46] Lazar et al. 2015, Level 5).

Step 7 — explain the why. The coach returns the session plus a one- or two-sentence rationale: "Rest day — your last session was hard and your ACWR is above 1.5," or "Steady 60 at 2:24, rate 20 — your CTL is rising and your last easy day was four days ago." The rationale is plain-language; it does not expose internal weights or models ([12] Cai et al. 2019, Level 5; [14] Miller 2019, Level 5).

Why the onboarding goal is a strong prior, not a setting

The onboarding goal is the strongest single input the coach has, and it is set by the rower at sign-up. The coach does not infer goals — it asks ([10] Amann et al. 2020, Level 5; [12] Cai et al. 2019, Level 5). This is a deliberate design choice, defended by three literatures.

The explainability literature. [10] Amann et al. (2020, Level 5) argue that AI systems in health-related domains should be transparent about their inputs and their goals; an inferred goal is an opaque input. Asking the rower for the goal at sign-up makes it auditable. The rower can change it; the coach cannot silently switch it.

The onboarding literature. [12] Cai et al. (2019, Level 5) — the "Hello AI" paper — studied how medical practitioners want AI systems to onboard them. The consistent finding: practitioners want an explicit moment of alignment ("here is what I am here to do") before the system acts. The coach's onboarding step is that moment.

The recommender-systems literature. [17] Schein et al. (2002, Level 5) and [15] Li et al. (2010, Level 5) both treat the cold-start problem (a new user with no data) by combining sparse observed signals with declared preferences. The onboarding goal is the declared preference; the Logbook history is the observed signal. The hybrid is more robust than either alone ([16] Burke 2002, Level 5).

The onboarding goal is not permanent. The rower can change it in chat: "I'm tapering for a 2K on the 14th," "I want to focus on technique for a month," "I'm coming back from injury, switch me to recovery." Each of these is a softer override than the original onboarding goal, but they accumulate — a rower who has said "tapering for a 2K" in chat three times in the last week has implicitly shifted their effective goal, and the coach treats the shift as live ([36] Kellmann et al. 2018, Level 5).

The safety rules, in detail

The four safety rules are non-negotiable. They are not preferences; they are guardrails. The design choice to make them non-negotiable comes from the IOC consensus on load in sport ([4] Soligard et al. 2016, Level 5) and the empirical literature on acute load ([5] Gabbett 2016, Level 2b; [6] Hulin et al. 2014, Level 2b).

No back-to-back hard sessions. The rationale: two consecutive high-intensity sessions are a well-documented injury risk in team sport ([5] Gabbett 2016, Level 2b; [42] Hulin et al. 2016, Level 2b) and the same general pattern is defensible for endurance training. The implementation: the coach classifies a session as "hard" if its load exceeds the rower's 30-day average session load by more than 1.5×; if the last session was hard, today's session is moderate or easy ([2] Foster 2001, Level 5; [20] Sanders et al. 2017, Level 2b).

Acute-load ceiling. The rationale: an ACWR above 1.5 is associated with elevated injury risk ([5] Gabbett 2016, Level 2b; [6] Hulin et al. 2014, Level 2b; [42] Hulin et al. 2016, Level 2b). The implementation: if the coach's computed ACWR is above 1.5, today's session is easy or rest, regardless of the calendar. The coach does not hide this rule from the rower; if the ACWR is the reason today is easy, the rationale says so.

Declared-illness veto. The rationale: training through acute illness is a documented risk for myocarditis and prolonged recovery ([39] Halson & Jeukendrup 2004, Level 5; [40] Meeusen et al. 2013, Level 5). The implementation: if the rower has said in chat that they have a fever, flu, chest cold, or any acute illness, today's session is rest. The coach does not require clinical-grade certainty — the rower's word is the input.

Declared-sleep veto. The rationale: severe sleep deprivation impairs performance, cognitive function, and immune response ([3] Halson 2014, Level 5; [37] Plews et al. 2013, Level 5; [41] Mah et al. 2011, Level 1b). The implementation: if the rower has said in chat that they slept under five hours, today's session is easy or rest. The coach does not require polysomnography — the rower's word is the input.

These four rules together implement the conservative default the post-2017 load-injury literature has converged on ([7] Bourdon et al. 2017, Level 5; [43] Verhagen & Gabbett 2019, Level 5; [44] Gabbett 2019, Level 5): when the dashboard says "hard" but the rower says "no," the rower wins; when the rower says nothing, the dashboard applies the conservative default.

The personalization literature: recommender systems for a small, sparse user

The coach is, at heart, a recommender system: given a rower and a context, recommend one session from a large but structured space. The personalization literature that informs this design comes from recommender systems, not from sport science — because the sport-science literature does not directly address the cold-start, sparse-data, evolving-user problem an adaptive AI coach faces ([15] Li et al. 2010, Level 5; [16] Burke 2002, Level 5; [17] Schein et al. 2002, Level 5; [18] Saveski & Mantrach 2014, Level 5).

Contextual bandits. [15] Li et al. (2010, Level 5) — the classical contextual-bandit paper from Li, Chu, Langford, and Schapire at Yahoo — formalised the problem the coach faces: a rower is a context vector (Logbook history, onboarding goal, chat preferences, load trend), each session is an action, and the reward is whether the rower completes the session, returns tomorrow, and does not get hurt. The contextual-bandit framework fits because the rower's context is sparse, the action space is large (every plausible session), and the system must learn online from limited feedback. The safety rules are bandit guardrails — they constrain the action space.

Hybrid recommenders. [16] Burke (2002, Level 5) surveyed hybrid recommender systems, which combine content-based and collaborative filtering. The coach is a hybrid: the content side is the rower's Logbook history, the collaborative side is the population-level defaults the coach inherits from the sport-science literature (polarised 80/20, ACSM weekly dose, autonomic-recovery emphasis). The hybrid is more robust than either alone — a rower with no Logbook history can still get a sensible default prescription, and a rower with deep history can get a prescription that diverges from the default ([17] Schein et al. 2002, Level 5).

Cold-start methodology. [17] Schein et al. (2002, Level 5) and [18] Saveski & Mantrach (2014, Level 5) addressed the cold-start problem: what to recommend for a user with no data. The coach's answer is the onboarding goal plus population-level defaults. As the rower's Logbook accumulates, the coach's recommendations become more individualised and the population default plays a smaller role ([26] Pyne et al. 2006, Level 5; [27] Kramer et al. 1994, Level 2b).

Session-based and time-aware recommenders. [19] Sun, Zhao, and Zhang (2018, Level 5) proposed time-aware, session-based recommenders that weight recent actions more heavily. The coach inherits this: the last ten sessions are weighted more heavily than the older ten, and chat said yesterday is weighted more heavily than chat said last week ([14] Miller 2019, Level 5).

The honest read: the coach is a small, well-instrumented contextual-bandit recommender system with hard safety guardrails and a context vector that the rower is expected to keep current. This is a deliberately conservative design — it does not learn online from population feedback the way a large recommender would ([10] Amann et al. 2020, Level 5; [11] Ghassemi et al. 2021, Level 5; [45] Impellizzeri et al. 2020, Level 5).

The transparency posture: declare what was read, declare what was synthesised, declare what was not

The coach returns the session plus a one- or two-sentence rationale. The rationale is the coach's transparency posture in action, defended by three literatures.

The explanation literature. [14] Miller (2019, Level 5) — the canonical social-science framing of explanation in AI — argues that explanations are social acts; the right shape of explanation depends on the audience. The rower is the audience; the explanation is plain-language, in chat, and tied to the rower's context.

The information-overload literature. [13] Kizilcec (2016, Level 5) showed that more information is not always better; dashboards can overwhelm and disengage. The coach's choice to return one session, not twenty, is a deliberate overload-reduction choice ([46] Lazar et al. 2015, Level 5; [49] Consolvo et al. 2006, Level 5).

The cautionary literature. [11] Ghassemi et al. (2021, Level 5) — the "false hope" paper — argued that current XAI methods in healthcare often overclaim and underdeliver. The coach's posture is conservative: it declares what was read (Logbook history, onboarding goal, chat preferences), it declares what was synthesised (the session and its rationale), and it declares what was not (sleep, soreness, life stress the rower did not share). The rower is the missing input the model cannot infer silently ([3] Halson 2014, Level 5; [38] Saw et al. 2015, Level 1a; [56] Düking et al. 2018, Level 5).

This is not a perfect transparency — full transparency would expose the internal weights and the population defaults, which would not help the rower and could mislead ([11] Ghassemi et al. 2021, Level 5). It is the right shape of transparency for a daily-prescription coach: one session, one rationale, one honest declaration of what was not seen ([10] Amann et al. 2020, Level 5; [12] Cai et al. 2019, Level 5).

What the coach deliberately leaves to the rower

The coach's three signal streams are bounded by what the Concept2 Logbook API exposes, what the rower said at onboarding, and what the rower has shared in chat. Anything outside those bounds is out of scope. This is not a defect; it is the design ([56] Düking et al. 2018, Level 5; [57] Düking et al. 2018, Level 5).

Sleep. The coach does not see the rower's sleep. It can ask in chat; the rower's answer is treated as a strong signal ([3] Halson 2014, Level 5; [37] Plews et al. 2013, Level 5; [41] Mah et al. 2011, Level 1b).

Soreness. The coach does not see the rower's soreness. It can ask in chat; the rower's answer is treated as a strong signal ([3] Halson 2014, Level 5; [38] Saw et al. 2015, Level 1a).

Life stress. The coach does not see the rower's work, family, or travel load. It can ask in chat; the rower's answer is treated as a strong signal ([3] Halson 2014, Level 5; [36] Kellmann et al. 2018, Level 5).

Heat and hydration. The coach does not see the rower's environment. A heat wave or a dehydrated rower will inflate sRPE without a corresponding rise in actual training load ([8] Sawka et al. 2007, Level 5; [9] Sawka et al. 1992, Level 5). The rower can tell the coach "it's hot today" and the session will adjust.

Equipment changes. The coach does not see the rower's drag factor unless the rower has logged it. A sudden damper change will not be inferred; the rower can mention it in chat ([60] Concept2 — Damper Setting, Level 5; [61] Concept2 — Damper and Drag of Olympians, Level 5).

Personal records and streaks. The coach does not see what the Logbook API does not expose — pre-computed aggregates, streaks, calendar views. It derives them client-side from the session list, but a rower who has not synced the Logbook will not see them ([1] Concept2 Logbook API docs, Level 5).

The honest read: the coach is a small, well-instrumented system with deliberate blind spots. The blind spots are documented; the rower is the missing input. The synthesis works only when both sides share ([48] Rapp & Cena 2016, Level 5; [49] Consolvo et al. 2006, Level 5; [55] Li, Dey & Forlizzi 2010, Level 5).

Behaviour and adherence: why the coach is one session, not a dashboard

The coach returns one session, not a menu. This is a deliberate design choice defended by the behaviour-change literature.

Abandonment. [46] Lazar et al. (2015, Level 5) — the "why we use and abandon smart devices" paper — identified nag, complexity, and irrelevance as the dominant abandonment drivers. A coach that gives the rower twenty metrics to interpret each day is a coach the rower will abandon. A coach that gives the rower one session to row is a coach the rower will use ([47] Yang et al. 2015, Level 5; [49] Consolvo et al. 2006, Level 5).

Habit formation. [50] Lally et al. (2009, Level 5) — the habit-formation paper — showed that habits take an average of 66 days to form, with substantial individual variation. The coach's daily-prescription cadence is a habit-formation intervention, not a feature ([51] Gardner & Lally 2012, Level 2b; [52] Ma et al. 2023, Level 1a).

Intrinsic motivation. [51] Gardner & Lally (2012, Level 2b) and [53] Michie et al. (2013, Level 5) — the BCT Taxonomy v1 — argue that intrinsic motivation and goal-conditioned prescriptions drive adherence more reliably than extrinsic rewards. The coach does not give badges, streaks-as-rewards, or extrinsic incentives; it gives a goal-conditioned session, and the rower rows ([52] Ma et al. 2023, Level 1a; [54] Schoeppe et al. 2016, Level 1a).

The bottom line: the coach's daily-prescription design is a behaviour-change intervention. The one-session-a-day shape, the plain-language rationale, the safety-guarded synthesis — all of it is in service of adherence, not of feature-completeness ([13] Kizilcec 2016, Level 5; [46] Lazar et al. 2015, Level 5; [50] Lally et al. 2009, Level 5).

Limitations and open questions

The coach does not see what the Logbook API does not expose. [1] Concept2 Logbook API docs (Level 5) defines the data surface; force-curve, pre-computed aggregates, and stroke-level force data are out of scope. The coach's model of the rower is bounded by this surface ([17] Schein et al. 2002, Level 5).

The cold-start problem is real. A rower with fewer than ten sessions in the Logbook gets population-level defaults with a wide confidence band. The coach is honest about this: it returns a default prescription and tells the rower to log consistently for two weeks ([17] Schein et al. 2002, Level 5; [18] Saveski & Mantrach 2014, Level 5).

The model does not learn online from population feedback. [10] Amann et al. (2020, Level 5) and [11] Ghassemi et al. (2021, Level 5) argue that online learning from health-related feedback is risky. The coach is intentionally conservative; it does not update its defaults from population-level signals in production.

The ACWR's predictive power is weaker than the 2016 evidence base implied. [5] Gabbett (2016, Level 2b) and the broader critique — [6] Hulin et al. (2014, Level 2b) and [45] Impellizzeri et al. (2020, Level 5) — give the coach a useful safety signal but not a verdict. The >1.5 band is treated as a warning; the 0.8–1.3 "sweet spot" is treated as a guideline; the rate of change is the most defensible signal.

The coach cannot infer silent inputs. Sleep, soreness, life stress, heat, equipment changes — all of these are inputs the rower must bring to the coach through chat. The coach is conservative about inferring them ([3] Halson 2014, Level 5; [38] Saw et al. 2015, Level 1a; [56] Düking et al. 2018, Level 5).

The recommender-systems literature is the design's main risk. [15] Li et al. (2010, Level 5) and [17] Schein et al. (2002, Level 5) are not validated in the rowing-specific prescription context. The coach's design borrows the framework but not the empirical validation; the rowing-specific validation is still to be done.

The transparency posture is conservative but not perfect. [11] Ghassemi et al. (2021, Level 5) is the cautionary frame: full transparency is impossible, and the coach's "declare what was read, declare what was synthesised, declare what was not" stance is a defensible but imperfect compromise.

What to do with this article

The coach is one session, one rationale, one safety-guarded synthesis of three signal streams: your Logbook history, your onboarding goal, and what you have shared in chat. The synthesis is the design; the safety rules are the guardrails; the chat is the place where you bring back the inputs the dashboard cannot infer silently.

Use the coach the way it is built to be used. Log consistently so the Logbook signal is current. Set your onboarding goal honestly so the default intensity distribution matches your aim. Tell the coach in chat when you are tired, sore, sick, or facing life stress — each is a signal the coach treats as live. Read the rationale, even when it is short, because the rationale is the coach's audit trail. When the rationale says "rest day — your ACWR is above 1.5" or "easy day — you slept four hours last night," trust it; the safety rules are non-negotiable ([4] Soligard et al. 2016, Level 5; [5] Gabbett 2016, Level 2b; [36] Kellmann et al. 2018, Level 5).

The coach is not a verdict. It is a synthesis, and the synthesis is only as good as the signals on both sides.