Brainstorm for what coach-facing analytics Hydrolyze should ship, framed by Cameron McEvoy's force-velocity lens, anchored in the literature and cross-sport practice, and grounded in the data Hydrolyze already captures.
Scope of this doc: ideas only, no implementation. The goal is to map the option space before committing to v1 of the analytics surface.
Hydrolyze already has a lot of the engine. The work for "data presentation" is mostly about surfacing what the engine already computes, plus a small number of new views. Concretely, the following primitives exist in ios-native/Hydrolyze/Sources/Services/:
SpeedCurveFitter.swift — log-log power-law fit (Riegel-based, default slope −0.165). Output: SpeedCurve { a, b, fitDistances, fitMethod }. The (a, b) pair IS the F-V operating point on a one-dimension view.HistoricalTimePredictor.swift — 3-layer prediction (recorded stats → speed curve → population), with a tiered confidence model (learning / reliable / excellent) and a 1500ms sigma floor.Welford accumulators in swimmer_gears and swimmer_intensity_calibrations — per-swimmer, per-gear / per-intensity mean and stddev.PairingEngine.swift — produces per-row confidence % already (in-session).WaveAllocator.swift — produces per-wave send-off and lane assignments.WorkoutService.swift + the schema (workouts, workout_sets, recorded_times, swimmers, swimmer_pbs, swimmer_gears, attendance, workout_set_completions).Implication: the "data capture working to an ok level" the user is referring to is real. The pairing engine already has the data it needs. The data presentation layer is mostly a view problem: turn the engine's output into coach-actionable displays.
McEvoy's F-V framing, taken seriously, generates a specific kind of dashboard. The "operating point" is the central object.
A scatter or line plot showing each swimmer's position on the F-V operating-point chart over the season. The x-axis is the force proxy (could be: dryland PB, set type distribution weighted toward resisted, gear mix, RPE mix). The y-axis is the velocity proxy (clean swim speed at a chosen distance, or the a coefficient from SpeedCurve).
A well-periodised squad should show a wave: high force / low velocity in autumn → low force / high velocity in summer. A swimmer whose operating point doesn't move is in the wrong phase. A swimmer whose operating point is on the wrong side of the squad's distribution needs targeted work.
Same chart, time-slider: scrub the season. McEvoy's three phases become visualisable:
The coach can ask: "where in the season am I? where is each swimmer relative to where they should be?"
SpeedCurve made visible)SpeedCurveFitter already produces a and b per swimmer. Today's prediction engine uses these internally. The coach view: the swimmer's a and b plotted against the population distribution. A swimmer with a high a (fast in absolute terms) and a steep b (loses speed quickly with distance) is a sprinter. A swimmer with a lower a and a shallow b is a distance swimmer. Most swimmers cluster in a band — outliers deserve attention.
McEvoy's frame: race day is one sample from a tight training band. The coach view: per swimmer, plot their 50m free times as a tight band (last 20 sessions at race intensity) with their PBs marked. The tighter the band, the more predictable their race. A swimmer with a 22.1 ± 0.1s band will race 22.0–22.2. A swimmer with a 22.1 ± 0.6s band is a coin flip on race day.
The view extends naturally to all distances and intensities: "their training band at this set is X ± Y seconds."
The user's prompt explicitly says "backed up by statistics." Variance is the right first statistical axis.
For each (swimmer, stroke, distance, intensity) bucket, the CV = σ / μ. Sprint literature (Stewart & Hopkins 2000) puts typical between-competition variation at 1.4%. Within-session variation is larger. A coach wants to know: who is consistent (low CV, repeatable) and who is variable (high CV, hot/cold)?
Data available: all of it. recorded_times joined to workout_sets gives the times; the HistoricalTimePredictor already computes the σ for the pairing engine — we can compute the same σ over the historical set.
Visual: per swimmer, a "consistency score" 0–100 (or a CV % with a sprint benchmark band overlaid). A simple number on the swimmer card. The "1 row needs review" indicator in SessionReviewView already points at variance — this is the same signal surfaced as a permanent property.
Ariana's 9×50 on 2:00 — range 68.9–72.2, rep 2 fastest, rep 6 slowest, back-half fatigue 36.4–38.5 — is a textbook example. The same data, for every set, for every swimmer, is a coach's gold.
Visual: per set, a line plot of rep times within the set. Reference lines for the swimmer's PB and the per-distance stddev band (from HistoricalTimePredictor). Surface:
The view extends to multi-set sessions: "across today's 3 sets, the 50 free times are descending" — a set progression.
A swimmer's CV should change with training phase. In a taper, CV tightens (less fatigue, more repeatable). In a build phase, CV can widen (more fatigue). A swimmer whose CV isn't changing across the season is in a flat periodisation state.
Visual: a CV-over-time line per swimmer, with phase markers overlaid. "Alice's CV is 2.1% in May → 1.4% in July" — taper working.
A formal test for negative split: are reps N+1, N+2, ... significantly faster than reps 1, 2, ...? (t-test, or just a sign test on consecutive pairs.) Surface as a "consistently negative-split" or "positive-split risk" flag.
Visual: a single badge per set, or a per-rep z-score plot.
For each (swimmer, stroke, distance, intensity, gear): a time series of PBs, with the all-time PB highlighted, the season PB highlighted, and a regression line.
Visual: a clean line chart with the slope annotated. "Improving 0.4s/year on 100 free at threshold" — a number a coach can act on.
The a coefficient from SpeedCurveFitter should drift over the season as the swimmer's PB improves. Plot a over time per swimmer. A swimmer with a stable a and a stable b is plateauing. A swimmer with rising a and stable b is improving in absolute terms. A swimmer with stable a and shallowing b is gaining endurance.
Visual: a per-swimmer chart with two lines (a, b) on dual y-axes, time on x.
For each (swimmer, stroke, distance, intensity, gear), what's their percentile vs the squad? "Alice is at the 70th percentile for 50 free at threshold." Useful for squad selection and for managing expectations.
Visual: a dot on a distribution per set type, or a percentile bar per swimmer. (Privacy: don't show this for tiny squads — the percentile is meaningless for n=3.)
A new metric: PB improvement per week, smoothed. A swimmer whose PB is improving fast is in a productive phase. A swimmer whose PB is flat is at a plateau. A swimmer whose PB is regressing is in an over-reaching state.
Visual: a per-swimmer sparkline, with green/amber/red bands.
For a given session: sum of (intensity multiplier × reps × distance) per set. A 10×50 at RPE 8 ≈ 10 × 1.03 × 50 = 515 (in some unit). A 20×100 at RPE 6 ≈ 20 × 1.10 × 100 = 2200. The numbers are arbitrary but the comparison is meaningful.
Visual: per session, a stacked bar by intensity band. Or a single number ("load = 1850") with a weekly trend.
Sum of session loads across a week. The "chronic" axis in the PMC framework.
Visual: a bar chart of weekly load, with the current week highlighted.
In TrainingPeaks, TSB = CTL − ATL. Translated to swim: ATL (7-day average) vs CTL (28-day average). A ratio > 1.3 = "fresh, building toward a peak." A ratio < 0.8 = "fatigued, taper needed."
Visual: a single number per swimmer with green/amber/red. Or a Performance Manager Chart: ATL line + CTL line + Form (CTL − ATL) line.
For each swimmer, plot session load (x) against next-day PB outcome (y). A swimmer who responds well to high loads is in a productive phase. A swimmer who responds poorly is at the edge of their envelope. This is the kind of analysis Catapult / WKO5 do for elite athletes.
Visual: a scatter with a regression line. Per swimmer.
The pairing engine already computes confidence %. The coach view should let the coach audit the engine.
For each set in a session, a strip showing the engine's confidence for each pairing. Green = high, amber = low, red = manual review needed. The coach can scan the strip and see which sets are problematic.
Visual: a thin strip per set, colour-coded by confidence.
The HistoricalTimePredictor already returns a maturity tier (learning / reliable / excellent). Surface it on the swimmer card. "Alice: 12 recorded times → reliable. Bob: 3 recorded times → learning."
Visual: a small badge. Helps the coach calibrate how much to trust the predictions for a given swimmer.
The engine computes σ per prediction. When a recorded time is far from the predicted band, the SessionReviewView should show why: "Fiona's 50 free was 0.6σ above her reliable band (her mean is 30.1s ± 0.4s, this swim was 30.6s)." The coach can decide if this is noise or signal.
Visual: a hint line under the recorded time in the review surface.
A pair of recorded times where the engine's best pairing contradicts the speed ordering: e.g., the slower PB swimmer has a faster recorded time. The engine will still pair correctly via Hungarian, but the coach wants to know "this pairing was non-obvious."
Visual: a flag on the row.
A single tap on the swimmer card: "felt off today" / "felt normal" / "felt great." Captures the same signal WHOOP / Catapult / Olav Aleksander Bu's VO2 Master methodology captures. Optional — coach asks the swimmer at the start of the session. Stored against the session.
Visual: a small dot on the swimmer card. Filter: show me the times from "felt off" sessions vs the times from "felt great" sessions.
If a swimmer was "felt off" today, the prediction for that session's sets should widen (higher σ). The engine's sigmaFloorMs = 1500 today; a "felt off" flag could bump it to 3000. The pairing confidence changes accordingly.
Visual: a confidence strip that explains itself ("low confidence: swimmer flagged 'felt off'").
WHOOP, Oura, Garmin Connect. Each can supply HRV, sleep, resting HR. Plug into the prediction engine. Out of scope for v1, but the schema should accommodate wellness_metrics(swimmer_id, date, source, hrv, sleep_hours, rhr).
All swimmers on a single F-V operating-point chart. A scatter where each dot is a swimmer, x = force proxy, y = velocity proxy. The coach can see the squad's distribution, the spread, the outliers. Useful for relay selection, for planning the season, for justifying individual work.
Visual: a scatter with squad median + spread bands.
For each session, the wave allocator's spread: "Wave 1: Alice 30.5s, Bob 30.7s, Charlie 31.0s, Diana 31.3s (0.8s spread)." "Wave 2: 32.5–36.1 (3.6s spread)." The coach can see if the wave allocation is producing tight races or if one wave is going to be a blowout.
Visual: a per-session wave preview with mean / spread / lane assignment.
For each set type, the squad's average PB improvement rate over the season. "Squad 50 free threshold PBs: 1.2% improvement in 8 weeks." Useful for the coach to communicate progress to swimmers and parents.
Visual: a single number per set type with a trend.
A ranking of swimmers by PB improvement rate. Sensitive — the coach's judgment, not the swimmers' eyes. (Privacy: coach-only view, with the option to share selected rows with individual swimmers.)
Visual: a sortable list.
Swimming Australia is rolling this out with Amazon Q in QuickSight. "How is Alice trending on 100 free over the last 8 weeks?" gets a chart. v2+ for Hydrolyze. The schema is rich enough to support this; the LLM is the missing piece.
Visual: a chat input. The LLM picks the chart, the data, the time window.
A coach types: "What if I added 2× 50 free at RPE 10 to next Tuesday's session? Alice's predicted load: +200. Bob's predicted load: +180 (he's at the edge of his envelope)." The system computes the load per swimmer and surfaces the risks.
Visual: a load-stacking simulator. Coach-side only.
The product principles say "effortlessness" and "information-rich." The analytics surface is on the information-rich end. The right answer: the analytics surface is off the main flow. The coach opens it when they want it, not during a session. During a session: the existing minimal surfaces (pairing confidence, swimmer card) suffice.
The pairing engine's default-to-assign contract is sacred. The analytics surface must NEVER change the pairing default. It's a separate view, a separate screen, opened on demand.
Analytics suggest, the coach decides. A "low confidence" badge is information, not a directive. A "Bob is regressing" insight is information, not a directive to drop him from the relay. The analytics surface respects the coach's authority by never making claims it can't back.
Mixing intensities is comparing apples to oranges. The current swimmer_intensity_calibrations table already supports per-(swimmer, intensity) calibration. The analytics surface should never mix RPE 6 and RPE 10 in the same trend.
The existing engine already gets better with more data. The analytics surface should encourage the coach to use it more. Show the maturation curve: "Alice's predictions are 3σ tighter than 8 weeks ago" — the coach sees the value compound.
If the user wants to ship a v1 of the analytics surface, the three highest-leverage views are:
The existing swimmer card shows: name, PB, predicted time, confidence. The v2 adds: maturity tier, CV at this set type, training band (mean ± σ from last 20 sessions at this intensity), 1-line "last 5 times" sparkline. The card stays glanceable. New data is small text, not new structure.
The F-V map (per swimmer, log-log speed-distance). One chart per squad, with all swimmers as dots. Outliers labelled. "Alice is at the 95th percentile for 50 free; 50th for 400 free." A coaching tool, not a session tool.
The rep-by-rep line plot for a set, with the swimmer's PB and ±1σ band overlaid. Per set, per session, in the post-session review. "Ariana's 9×50: 68.9, 69.1, 70.3, 71.0, 71.4, 72.2, 71.8, 70.5, 69.7. Rep 2 fastest, rep 6 slowest, back-half fatigued. Mean 70.5 ± 1.0s." The coach's gold.
These three are the smallest set that exercises the engine, the visualisations, and the coach workflow. Ship these, then iterate.
SpeedCurveFitter.swift, HistoricalTimePredictor.swift, PairingEngine.swift, WorkoutService.swift, schema migrations)concepts/rpe-rate-of-perceived-exertion, originals/rpe-nomenclature-for-hydrolyze-intensity, people/ariana-carter, people/jack-burchell
Published and managed by TARS, an AI co-author built on Nathan's gbrain.