Contents
How TrainingPlan Chooses Training Phases
See a reproducible example of TrainingPlan's calendar-based phase planning, what changes when the planning window changes, and what phase labels cannot tell you.
Quick Hits
- •TrainingPlan's phase schedule uses the planning window and goal type.
- •A phase change is not confirmation that your body has adapted or recovered.
- •Shortening the planning window can shorten base and build allocations.
- •Session adjustments and phase selection are separate parts of planning.
- •The worked example runs the current scheduling function with synthetic inputs.
TrainingPlan's phase schedule is driven by the available planning window and goal type. The implementation reviewed for this article does not wait for an aerobic-efficiency plateau or a recovery score before moving from base to build.
That distinction matters when you read a generated plan: a phase label describes the scheduled emphasis, not a measurement of your body's readiness. Here is a reproducible example of what the software actually calculates.
Phase Labels and Weekly Sessions
For the general idea of organizing training emphasis over time, see periodization for normal runners. This article focuses on TrainingPlan's mechanism.
The current code uses BASE, BUILD, PEAK, TAPER and MAINTENANCE labels. Their order and duration come from scheduling rules. Weekly session targets are then calculated using the phase alongside other inputs, such as running-day count and runner-level rules.
A label alone is not a complete training prescription. For example, the PEAK label in the example below denotes the final week after the taper. It is not a finding that fitness has reached a peak. Longer planning windows can also contain additional cycles or an intermediate taper/peak block; the example is not a universal pattern for every plan.
A Worked Planning-Window Example
Synthetic software example, checked September 7, 2026. We ran the current phase-scheduling function with a half-marathon goal and 12 total planning weeks, then changed only the available weeks to 10. No customer data, fitness measurements or account edits were used.
| Phase | Initial input: 12 weeks | Changed input: 10 weeks |
|---|---|---|
| BASE | Weeks 1–4: 4 weeks | Weeks 1–3: 3 weeks |
| BUILD | Weeks 5–9: 5 weeks | Weeks 4–7: 4 weeks |
| TAPER | Weeks 10–11: 2 weeks | Weeks 8–9: 2 weeks |
| PEAK | Week 12: 1 week | Week 10: 1 week |
| Total | 12 weeks | 10 weeks |
What changed: the base allocation fell from four to three weeks and the build allocation from five to four. The two taper weeks and final peak week remained.
Why: for these inputs, the scheduler reserves two taper weeks for the half-marathon goal and one final week. It divides the remaining window between base and build using its allocation rules. Twelve weeks leave nine for that split; ten leave seven. This calculation explains the changed phase boundaries without assuming that the runner adapted faster.
In the weekly-target builder, the number of weeks is counted from the planning window, through the goal-race week when a race date is available. A changed date can therefore change the input to phase scheduling when a plan is generated. The example directly exercises that scheduling input; it does not demonstrate that editing a date in an account instantly replaces all saved sessions.
What the example does not establish: that ten weeks are sufficient preparation, that compressing a plan is appropriate after illness, or that either output improves race results. Those questions require information beyond the phase allocator.
Automatic Calculations and User Inputs
“Automatic” below means calculated when the relevant generation code runs. It does not mean every saved plan is continuously rewritten in the background.
| Category | Demonstrated behavior | Practical limit |
|---|---|---|
| Calculated automatically during phase generation | Divide the available weeks into cycles and phases using goal-specific rules | Calendar allocation does not measure adaptation |
| Calculated during weekly-target generation | Apply phase/level/running-day rules and adjustment modifiers to session targets | A distance or quality-session change is separate from moving phase boundaries |
| Requires supplied or resolved planning inputs | Use the goal type and planning window; the wider builder uses the goal-race date when available | Confirm that the plan reflects your actual goal and dates; the example does not verify an account editing flow |
| Requires a user decision | Decide whether the displayed plan fits changed circumstances and whether to request a change | A generated output cannot make a health or recovery decision for you |
| Not inferred by the phase allocator | Readiness from sleep, HRV, cardiac drift, aerobic plateaus or race-pace sharpness | None of these is an input to this phase-selection function |
| Not demonstrated by this mechanism | Prioritizing multiple real races or optimizing a multi-year race calendar | An intermediate programmed peak does not establish either capability |
The plan-adjustment guide explains how to separate inputs, proposed changes and review. That is a different task from reading the phase calendar.
Missing or Noisy Data
An incorrect goal or date can produce an internally consistent schedule for the wrong planning problem. A correct total-week calculation cannot fix that input error.
This phase allocator does not use sleep or heart-rate variability, so missing those measurements is not evidence that it can infer recovery from something else. Likewise, a noisy activity record and a scheduled phase transition should not be interpreted together as proof that a phase's physiological purpose has been achieved.
Estimated session duration is another separate calculation: the duration helper uses an explicit duration in the planned workout details when available, otherwise distance and pace or fallback estimates. A duration estimate does not select the phase or assess readiness.
Review the Result Before Following It
- Check the goal and the planning dates against what you intend to do.
- Compare the phase calendar with the actual weekly sessions, including recovery and other commitments.
- If the available window changes, review the resulting plan rather than assuming fewer weeks simply require faster progression.
- Keep recovery advice and changed circumstances in the decision even when the calendar says BUILD or PEAK.
Method note: this example was reproduced against TrainingPlan's phase-scheduling implementation at code revision 3152c04. It is a deterministic function demonstration, not an authenticated account walkthrough, a customer outcome or a validation study of the training rules. The phase and duration code was inspected separately from the weekly adjustment logic.
Key Takeaway
Treat the phase calendar as a planning output. Check the inputs and resulting sessions, and keep your own circumstances and recovery advice in the decision. A scheduled transition is not evidence that you are ready for it.
Frequently Asked Questions
Does AI decide when I am ready for the next phase?
What changes when fewer weeks are available?
Is the peak label a fitness assessment?
Are session adjustments the same as changing phases?
References
- TrainingPlan phase-schedule implementation reviewed at commit 3152c04
- Reproducible synthetic phase-schedule example, September 7 2026