How we check the planner before you see a plan

A training plan is advice about your body, so “it seems to work” is not good enough for us. This post describes how we check the planner, and where checking stops.

The planner is built to be testable

The planning engine is a pure function. Given the same answers and start date it returns the same plan, because it reads no clock, uses no randomness and calls nothing outside itself. That makes it possible to test thoroughly, and to keep tests from flaking.

Four layers of checks

1. Unit tests. Each part of the logic, from reading a time like “27:45” to deciding where an easier week falls, has tests for normal and edge cases. Every input is validated, and bad or missing answers produce a clear message, not a guess.

2. Safety rules checked on every plan. We wrote a list of things a plan must never do, and a checker that applies it to a plan. A few examples from that list:

• Never schedule a run on a day you did not choose.
• Never exceed the time limit you set for a run.
• Never include more than one hard session in a week, or hard running beyond a short limit.
• Never leave a week without a rest day.
• Never show a pace range unless you gave a recent race.
• Never put strides in the first week.
• Always end on race day, with exactly one race session.

3. Property-based tests. Instead of a handful of hand-picked cases, these generate many combinations of answers and run the safety checker on every plan produced. They are good at finding the odd corner we did not think of.

4. Reviewed example runners. We keep a fixed set of example runner profiles, from beginners to experienced runners and from tight to generous timelines, and review their complete plans whenever the engine changes. A snapshot test fails if any plan changes unexpectedly, so a change has to be deliberate.

Key statements on this site are tested too

When a page says, for example, that a half marathon plan tapers over two weeks, or that a plan will not start after a recent injury, a test confirms it. If an engine change breaks one of those statements, the tests fail and point to the copy to fix. Not every sentence is covered, so this is a safeguard and not a guarantee. The tables in our analyses are generated from the engine itself.

Where checking stops

Tests show that the planner follows its own rules. They cannot show that the rules are right for you. The rules are conservative planning heuristics, not proven injury-prevention thresholds, and they have not yet been reviewed by a qualified running coach or a sports-medicine clinician. The planner cannot assess your health and is not medical advice.

We think that is the honest way to describe it: carefully tested software that follows cautious rules, with a clear note about what has not been reviewed. See our method for the full account.