Recovery

Why WhyRep will never tell you to deload

Most apps treat a deload like an oil change. Every fourth week, or every sixth, back off, then carry on as before.

WhyRep won't ever suggest one. Not on a schedule, not when you're beaten up, not at all. There's no threshold hiding somewhere that triggers it, because the list of conditions under which the app prescribes a deload is empty.

That empty list is the decision, not a gap somebody forgot to fill in. Here's the reasoning, and what happens instead.

The short version

• WhyRep never prescribes a deload. The approved trigger list for one is empty on purpose.
• It does recognise the ones you take yourself, if you flag them.
• When the evidence says you're not recovering, the program gets changed permanently instead.
• That change is one set off, then a two week wait to see what happens.

Why the list is empty

If a week off is what makes the next month work, then the month before it asked for more than you could recover from. A deload buys you a week and hands the same program back.

That's the position, stated plainly: a needed deload is a symptom, and the thing worth treating is whatever produced it. So rather than pausing a program that isn't working, WhyRep changes it and expects the change to stick.

It still sees the ones you take

Never prescribing isn't the same as refusing to look. If you drop the weight and flag the drop as deliberate, WhyRep records it, gives the session no verdict, and starts a fresh baseline from there. Your history doesn't get marked as a regression for something you chose to do.

If the weight drops and you don't flag it, that's a regression, and it counts as one. The flag is the entire difference, because it's the only thing that tells the app which of the two just happened.

What counts as evidence that you're not recovering

Two signals, and deliberately only two.

The first is soreness at the start of a session, logged in the muscles you're about to train. Not soreness in general, and not soreness you picked up from something outside the gym, which is a separate reason with a separate meaning.

The second is patterns in the verdicts themselves. The one that acts on a single muscle is called local overreach: two consecutive regressed sessions on one region while the rest of the program is doing fine. That routes to a volume reduction on that region, and nothing else.

Flat verdicts never trigger any of this. A run of flat sessions is a plateau question, and plateaus have their own windows scaled to training experience and muscle size. Regression is the signal here, because regression is what says you went backwards rather than stopped moving forwards.

Two things that were considered and thrown out

Worth naming, because their absence is a choice rather than an oversight.

Daily readiness check-ins aren't used. The app doesn't ask how recovered you feel and then act on the answer.

RIR drift was dropped as redundant rather than as wrong. Under the effective-reps metric, the same weight for the same reps at a lower RIR is already a regression verdict, so a second mechanism watching the same thing would just be counting one event twice.

What happens instead of a week off

Under-recovery never gets called on one bad week. The first week signals show up, the app cites the reasons that match and the fixes attached to them. That's it.

If the signals are still there the following week, what happens next depends on what you did about the first message. If you addressed the cited issue and the signals persist, the lifestyle explanation is spent, so under-recovery gets flagged and the program is what changes. If you didn't address it, the app keeps naming the same issue, because the program isn't guilty while the lifestyle is unexamined.

And if you explicitly decline to change it, there's an in-app action for exactly that. Then the app accepts your reality and adjusts the program to the life you actually have. It requires you to say so. It's never assumed on your behalf.

The cut is one set, and it stops

When under-recovery is flagged, the correction is one set off that region. Not a percentage, not a week off. One set.

The app states the number and never picks the set. It won't decide that your third set of incline press is the one to lose. You choose which set goes, and the count gets recalculated from what you actually did.

Then it stops and watches for two weeks. That window is a probation: no new under-recovery flags fire during it, because the change needs time to either work or not work.

If you're progressing again after the window, the episode is cleared and normal monitoring resumes. If you're still signalling, one more set comes off and a second probation starts. If you're still signalling after that one, there's no third cut. The app stops removing volume and says plainly that something outside the set count is likely involved, a pre-workout problem or a life problem.

That last part is the bit worth noticing. Cutting a third set would be the app doing the only thing it knows how to do, rather than the thing the evidence actually supports.

It signals, it doesn't dictate

The same stance runs in the other direction. When you reach the top of a programmed rep range, the app announces that the overload has been earned and explains why. It doesn't hand you a number.

No prescribed loads, no percentage jumps, no target weights. You pick what goes on the bar. The app's job is to tell you what your own logbook says, not to run your session for you.

Where this actually sits today

Being precise, because a signed document and shipped software are two different things: none of the detection on this page runs in the app yet.

There's no recovery engine in the codebase. As of the last check against the code, the engines directory held progression detection, plateau detection and the issue policy, and nothing else. The routing described above also depends on the program adjustment engine, which doesn't exist either.

What is settled is the policy and the rules. The deload stance is final, and it's the reason there's nothing to build here. You can't ship a deload prescriber for a product whose approved trigger list for one is empty. The detection and the escalation ladder are written, signed, and waiting on the engines that'll run them.

The part that is live is the piece all of this depends on. Regression and flat verdicts get produced today, per exercise, from your logged sets. That's the input this whole system reads.

Common questions

Should I deload every 4 to 6 weeks?

WhyRep won't tell you to, on that schedule or any other. Its approved list of conditions for prescribing a deload is empty, because the position in the methodology is that a program which needs a scheduled week off is a program to fix rather than a program to pause. If you choose to take one, the app records it without arguing.

Does WhyRep track a deload I take myself?

Yes. Drop the weight and flag the drop as deliberate, and the session gets no verdict and starts a fresh baseline. Drop the weight without flagging it and it's recorded as a regression, because nothing distinguishes it from one.

What does WhyRep do if I keep regressing on one exercise?

Two consecutive regressed sessions on one muscle region, while the rest of your program is fine, is treated as local overreach. The response is to reduce that region's volume by one set, then watch for two weeks before doing anything else.

Is under-recovery detection in the app right now?

No. The policy and the rules are signed, but the recovery engine hasn't been built. The progression and plateau verdicts it would read are live today. The detection on top of them isn't.

A note on sources

Everything on this page comes from WhyRep's autoregulation and deloads methodology document, signed before implementation. One number that's in that document is deliberately not on this page: the threshold for the wider, whole-program version of the signal. The document flags it as not yet re-tuned, and publishing past a flag like that is the one thing worth refusing to do. The local rule, which isn't flagged, is here in full.

Related reading

The verdicts this page reads are defined in what counts as progressive overload, and the flat runs deliberately excluded from it are covered in how many stalled sessions actually counts as a plateau.