Navin Benoy

Personal case study · 05

How to build a plan that rewrites itself from the data every week

Personal build · Claude connected to Garmin · 18 weeks to the Sydney Marathon

2 min read

619 km

Run across 57 runs in 18 weeks, up from a 9 km longest run at the start.

18 weeks of training, from Garmin

Weekly distance (km)Longest run that week (km)G1–G4: checkpoint gates
Base · wk 1–4Build · wk 5–9Peak · wk 10–15Taper · wk 16–180102030405060G1G2G3G4123456789101112131415161718Training weekRace week
View the data
WeekStartsRunsTotal kmLongest km
127 Apr211.06.0
24 May17.07.0
311 May424.110.0
418 May833.112.0
525 May419.47.0
6 (gate)1 Jun441.016.0
78 Jun220.010.0
815 Jun456.021.0
9 (gate)22 Jun233.023.0
1029 Jun235.025.0
11 (gate)6 Jul233.023.0
1213 Jul338.421.4
1320 Jul340.126.0
1427 Jul344.030.0
15 (gate)3 Aug353.035.0
1610 Aug344.024.0
1717 Aug331.015.0
1824 Aug456.042.9

The situation

I had 18 weeks to prepare for the Sydney Marathon. I started from 10 to 20 km a week, with a longest run of 9 km.

The real problem

A plan written in full up front assumes every week goes to plan. Mine didn't. I planned 4 runs a week and often delivered 2 or 3. The watch's defaults were also wrong for me.

The decision

Build each week from the last week's actual results, not a plan written in advance. Claude analysed the data and set the workouts. I kept the final calls.

How to work it

  1. Set goals and gates with numbers.

    An A goal, a B goal, and a C goal of finishing healthy. Four phases: Base, Build, Peak and Taper. Checkpoint gates in weeks 6, 9, 11 and 15, each with a pace and heart-rate target and a go/no-go result.

    TIP

    When you miss a gate, recalibrate. Don't hope.

  2. Connect the plan to the data.

    Claude connected to my Garmin through an API. It put each week's runs on my watch and pulled every session back afterwards.

  3. Review trends, not single sessions.

    Each week it looked at pace, heart rate against zones, splits, elapsed time, stopped time per lap, and planned against delivered run days. Stopped time showed every long run had stops in it.

    TIP

    Judge long runs on elapsed time. Moving pace hides the real problem.

  4. Fix the defaults before trusting the numbers.

    • My measured max heart rate was 205, not the default 195, which shifted every zone.
    • Race predictions ran 5–8% optimistic against real results.
    • Auto-generated workouts cluttered the calendar and were removed.
    • Hill runs moved to heart-rate targets so the watch stopped pushing for pace on climbs.

  5. Change one lever at a time, based on the data.

    Easy runs were being done at 92–94% of max heart rate, which is threshold effort, so they switched to a heart-rate cap with pace by feel. In the Peak phase a fourth run day was added: 30–40 minutes easy on Wednesdays. Frequency was the missing lever, not intensity.

    TIP

    Name the priority session each week, so the right one survives a busy week.

  6. Turn failures into rules.

    A new gel on a 35 km run cost me 65 minutes. "Nothing new on race day" became a hard rule.

What happened

Over 18 weeks I ran 619 km across 57 runs, with a peak week of 56 km and a longest training run of 35 km, up from 9 km at the start. I finished healthy and met the C goal. I missed the A goal by about 38 minutes, for the reason the gates had already flagged: continuity. I had never run long without stopping.

Use this when

  • A plan depends on how you actually perform, not how you hoped to.
  • You want AI to analyse the data and hold you to the plan, while you keep the decisions.