Contents
Adaptive Training Explained: Inputs, Decisions, and Review
Understand the adjustment loop and evaluate what changed, which inputs were used, and what still needs your judgment. Includes a worked change record.
Quick Hits
- •An adaptive process revisits a plan using new information.
- •A recorded metric, an interpretation and a changed workout are different things.
- •More data does not automatically make a recommendation correct.
- •A useful explanation identifies the trigger, assumptions, scope and result.
- •Review the output and retain room for your observations and professional guidance.
Adaptive training means revisiting a plan when new information matters. A coach can do this, a runner can do it, and software can implement parts of the process. The label alone does not tell you which inputs are used or whether a particular recommendation is appropriate.
This is a guide to inspecting that process. For deciding whether your current schedule needs a change, use when a fixed plan needs adjustment.
Separate the stages
| Stage | What to identify | What can go wrong |
|---|---|---|
| Input | What was recorded or reported, and when? | Missing sessions, wrong units, stale preferences or missing personal context |
| Interpretation | What meaning was assigned to the input? | Treating one observation as a diagnosis or assuming a cause |
| Decision | Which rule or judgment selected a change? | A hidden rule, an unsuitable assumption or a conflict with another constraint |
| Output | Exactly which days or details changed? | A saved setting without the expected calendar change, or an unintended change elsewhere |
| Review | Did the result address the original problem? | Assuming that generating a new plan proves it is better |
A missed workout is an observation. Why it was missed is additional information. What to do next is a decision. Keeping these separate prevents a blank activity record from silently becoming a claim about fitness or motivation.
Inputs have different meanings
Completed activities can describe what was recorded. Preferences describe what you want scheduled. A self-report can add information that a device cannot see. None is a complete account of the runner's circumstances.
Before relying on an automatic change, ask whether the input is actually supported, current and used in that decision. An app displaying sleep, heart rate or HRV does not by itself demonstrate that those fields modify the plan. This article does not claim that TrainingPlan automatically changes tomorrow's workout from those metrics.
More data also brings more opportunities for missing or inconsistent records. A useful service should let you distinguish “no activity recorded” from “confirmed rest,” and explain what it does when information is uncertain. Those are evaluation questions, not claims that every product already meets them.
Worked change record: moving a long-run preference
Illustrative situation: Sunday is no longer available for a recurring long run. Saturday may work, but an existing Friday workout could conflict with the new arrangement.
| Record field | Example |
|---|---|
| Trigger | A recurring Sunday commitment changed availability |
| Known information | The current calendar and the proposed Saturday slot |
| Missing information | Whether the surrounding sessions and total week remain appropriate |
| Proposed action | Review recurring preferences and the affected days |
| Constraint to inspect | The Friday/Saturday arrangement and other conflicts |
| Output to verify | The actual resulting calendar, not only the saved preference |
| Follow-up | Reassess whether the new arrangement fits in practice |
This is a scheduling example, not a direction to place a hard workout next to a long run. It does not prescribe training volume or infer recovery status.
TrainingPlan settings include conflict checks for long-run, workout and rest-day preferences. The plan calendar opens day details for inspection and offers week reordering. Regeneration is a separate account-dependent action with a confirmation flow. Review the available options and resulting days rather than treating these controls as interchangeable.
Separate product check, September 8, 2026: in an isolated synthetic account with a Wednesday workout, saving Saturday instead of Sunday as the long-run preference survived reload but changed none of the 21 existing calendar records. This verifies a saved input, not an automatically adjusted week. A subsequent week reorder and regeneration required separate actions.
The regeneration scope also mattered: future-only preserved an earlier completed fixture plan day, while full regeneration removed the older plan records, including that completed day. See the verified before-and-after example for the exact dates and limits. Do not treat “full” as a promise to preserve plan history. These observations concern stored plan days, not a test of imported-activity deletion.
Inspect a change before relying on it
- Trigger: Can you identify why a change was proposed?
- Inputs: Are the relevant dates, preferences and recorded sessions correct?
- Scope: Is one workout changing, a week being reordered, or a larger range being rebuilt?
- Preservation: What happens to existing entries and completed history under the selected option?
- Consistency: Does the resulting week fit the reason for changing it?
- Uncertainty: What context remains missing, and who can help assess it?
A sensible result may be to keep the plan, change a constraint, or pause the decision while obtaining more information. There is no requirement to accept a recommendation merely because a system generated it.
What an explanation should say
Compare “Your workout changed” with an explanation that identifies the supplied constraint, the affected dates, the action taken and what still needs review. The latter is more inspectable. It still does not prove a medical or performance benefit.
Do not accept an unexplained load-ratio threshold as proof of injury prediction, a numerical claim that software provides a fixed percentage of a coach's value, or a promise that every additional week of data makes predictions more accurate. Those claims need their own evidence.
Keep a before-and-after note
| Question | Your note |
|---|---|
| What did I report or change? | |
| What did the service say it used? | |
| What action did I approve or perform? | |
| Which dates and sessions actually changed? | |
| What assumption or result do I need to question? | |
| When will I review whether the change helped? |
The goal is an understandable decision process, not automatic deference to a metric. Your observations and appropriate professional guidance remain part of evaluating the plan.
Key Takeaway
Evaluate adaptive training as an inspectable process: inputs, assumptions, decision, output and review. Do not infer a capability or outcome from the label AI or from the amount of data collected.
Frequently Asked Questions
Does adaptive training always mean AI?
Does every app use HRV or sleep to change tomorrow's workout?
Should I trust the app over how I feel?
How can I tell whether an adjustment was useful?
References
- TrainingPlan plan calendar and regeneration implementation, reviewed September 2026