Statistics

Say your week closed on Sunday night and the system is about to stamp a single "good week" on it. Before stamping it asks three separate questions: did you lift heavier, how much work did you do, how well did you recover.

The week is measured by three independent scores, all computed in the same pipeline in the same order: first which channels carry data, then progress, then recovery, then load.

A single score would hide three different truths. A week of hard training with no recovery and a week of light training with good rest can produce the same average, yet the advice for them is diametrically opposed. The order is not arbitrary either: the sufficiency assessment is an input to all three scores, because a channel with no data gets no score.

One low score does not invalidate the others. Looking at which score fell tells you which side of the week to change.

The system calls this the "weekly scoring pipeline".

Say last week you finished squats at 3×10 · 40 kg and this week did the same movement at 3×10 · 42.5 kg. The system derives a progress score from that single movement.

The progress score is a fixed-weight sum of four parts: data quality 0.20, progression rate 0.50, movement coverage 0.15, estimated one-rep-max bonus 0.15.

Half the weight sits on the progression rate because that is the real question: in how many matched movements did you progress. One of three routes suffices for a movement to count as "progressed" — your best set’s weight rose, its reps rose, or your weekly total volume in that movement rose. Requiring all three would ignore the user who holds the weight and adds reps. The coverage part counts six distinct movements per week as full, so that progress in one movement is not credited to the whole week.

In a week where you cannot add weight, adding reps counts too. Without sets · reps · weight in your training log, this score has no input at all.

The system calls this the "progress score".

Say one week you did 40 sets but all light; another week 25 sets, most of them heavy. Those are not the same load.

The load score comes from four parts: set volume 0.30, tonnage density 0.30, movement variety 0.20, intensity spread 0.20. Forty sets a week counts as a full volume signal.

Counting sets alone is misleading: 40 light sets and 40 heavy ones would produce the same number. So tonnage per set enters as a separate part and is scored in tiers — 50 kg and above per set scores full, above 25 kg scores 0.7, above 10 kg 0.4, below that 0.15. Variety and intensity spread then distinguish the week that shows high volume by repeating one movement over and over.

Raising the weight without raising the set count also raises the load. Leave the weight field blank and tonnage density cannot be computed, so the score’s second part drops.

The system calls this the "training load score".

Say you entered an average of 7 hours of sleep a night, "good" quality, 3/10 soreness and 4/10 stress in your weekly recovery log.

The recovery score comes from four inputs: sleep 0.30, your self-reported quality 0.35, soreness 0.20 (inverted), stress 0.15 (inverted). Seven to nine hours of sleep scores full.

The largest weight sits on your self-reported quality because sleep duration alone does not describe recovery: it is possible to lie down for 8 hours and wake unrested. The sleep band falls at both ends — 12 hours and above scores as low as 4 hours and below. Once the score drops under 0.40 an "attention needed" flag lights, and that flag directly affects load recommendations.

Skip the recovery log and this score is not computed, leaving the week’s judgement fed by training alone. One minute of logging once a week is enough.

The system calls this the "recovery score".

Say your week went well and you expect your plan to get heavier next week. The system first asks: how well could I measure this week.

The decision passes three gates whose bounds depend on your goal: below the lower bound the plan does not change, in between observation continues, above the upper bound the plan is adapted. The defaults are 0.30 and 0.60; on a strength goal 0.35 and 0.75.

The bar is higher on a strength goal because a wrong increase there is a direct injury risk; on fat-loss or hypertrophy goals the same mistake costs less. Without the gate, a half-measured week would carry as much say as a fully measured one — and the boldest recommendations would appear precisely when data was scarcest.

If your plan is not changing that is not a fault: the system is saying it could not measure enough. Fill the missing channel and the decision gate opens.

The system calls this the "confidence gate".

Say you had three great weeks in a row and the system decided to "increase your volume". How large is the increase?

The amounts one adaptation can change are capped: volume at most ±10%, set count at most ±2, rest between sets at most ±30 seconds, daily calories at most ±200 kcal.

Without a cap, one good week could double the plan, and the user who cannot handle that volume the next week faces both injury risk and the feeling of having failed. The step size is fixed too: one set means ±5% volume, the rest step is 15 seconds, the calorie step 100 kcal. So no more than two steps are applied at once.

If the increase looks small, that is a deliberate cap rather than timidity. Applied several weeks running, the total change grows.

The system calls this the "adaptation safety bound".

Say your bench press target is 8-12 reps, you hit 12 on your last set, and your exertion rating was 7/10.

Reach the top of the rep band with reasonable effort and the weight goes up one step; the default step is 2.5 kg.

An exertion rating of 9.0 or above blocks the increase, and 9.5 or above lowers the weight — even if you hit the rep target. The reason is simple: if you barely made your last rep, settling one more week at the same weight progresses you faster than piling on. On a fixed rep target, an increase requires going 2 reps above the target; drop 2 below the band’s lower bound and the weight is reduced.

Entering the exertion rating in your set log directly affects the increase decision. Without it the engine looks only at rep count and may read a hard set as an easy one.

The system calls this the "minimum progression suggestion".

Say you have been stuck at the same weight for three weeks and your sleep has deteriorated, but you follow the programme to the letter. Will the system tell you to back off?

Deload candidacy requires all three to hold at once: a detected plateau, low recovery (0.30 or below) and positive programme adherence. When all three hold, the decision turns to hold and the plan is not changed.

All three are required to prevent false alarms: a plateau alone can indicate a technique problem, poor sleep alone a one-off week, and low adherence alone a dip in motivation. Seen together the picture changes — the person is training, training consistently, and still not progressing. That is the classic signature of insufficient rest.

Your programme saying "keep it the same this week" is a deliberate brake, not a punishment. Investing that week in sleep and nutrition is what makes the next increase possible.

The system calls this "deload candidacy".

Say you have finished lat pulldowns at 4×8 · 55 kg for three weeks; neither weight nor reps changed.

If a movement stays at the same best-set weight and the same reps for three consecutive weeks, a plateau is flagged.

The three-week threshold does not vary by goal — strength and hypertrophy use the same number. Two weeks was too early: a week of fatigue or one bad day would be taken for a plateau. The chain breaks the moment a measure changes between two weeks; so a single instance of progress resets the counter.

On a plateau warning, change something in that movement: the weight, the reps or the movement itself. Holding all three constant produces the same warning in week four.

The system calls this "plateau detection".

Say you raised your volume week after week but your sleep and soreness ratings got worse.

If the load score climbs to 0.85 or above while recovery falls below 0.40, a high-level overuse risk is written; with load above 0.70 and recovery again below 0.40, a moderate risk.

Neither score means much alone; their intersection does: high load with good recovery is the desired picture, and low recovery with low load is harmless. What produces the risk is the gap between them. That is why the thresholds are defined in one place, over two variables.

On a risk line, look at both scores: fix whichever side opened the gap — cut volume if load climbed, sort out sleep if recovery fell.

The system calls this "overuse risk".

Say you entered no recovery log this week. Does your recovery score show as 0?

No: with no log the score is not published at all. Without training records, the plateau and load scores are likewise carried as "absent" rather than a computed zero.

Zero is a measurement and says "I measured, the result was zero". Writing zero for something you did not measure would be making that same statement without evidence — and zero also drags every average down and makes the week look worse than it was. The distinction is deliberately preserved at the pipeline’s exit, and on an error all three signals fall to "absent" rather than to an invented value.

A field you leave blank does not punish you; it only narrows what the system can tell you. The module readiness list shows which field is doing the narrowing.

The system calls this "separating absent from zero".

Say your training records are complete but you never touched the nutrition and measurement sides.

The confidence score is a weighted sum of four channels — training 0.35, nutrition 0.30, body 0.20, recovery 0.15 — where a sufficient channel brings 1.0, an insufficient one 0.3 and an absent one 0.0. For the week to count as "sufficient" overall, at least three channels must be filled.

The channel weights are unequal because they do not say the same thing: without training records there is nothing to say about progress, while a recovery log refines an existing picture. An insufficient channel scoring 0.3 rather than zero is deliberate too — partial data is not no data, but neither does it count as complete data.

A week that fills three channels produces a more reliable report card than one that half-fills four. Which three is up to you.

The system calls this "channel-weighted confidence".

Say the journey card reads "Medium confidence" and you wonder what that is numerically.

A confidence score of 0.70 and above is high, 0.40 and above is medium, below that is low; if no score could be computed at all, "insufficient data" is written.

Keeping the band boundaries in one place stops the screen inventing its own threshold. There is also a fourth level, deliberately separate: low confidence is a measurement result, insufficient data is notice that no measurement could be made. Merging them would tell a user who entered no data at all that "your confidence is low".

On "insufficient data", fill the missing channel; on "low confidence", deepen the channels you already have.

The system calls this the "confidence level".

Say you opened the screen, your measurement data loaded in stages and the screen redrew several times. What if a new question went to the server on every redraw?

A fingerprint of the input sent for the progress assessment is kept; if the fingerprint is unchanged no new request is made, and if it changed the old answer is dropped.

There are two protections at once. First, redundant requests are prevented. Second and more important: if the input changes while an answer is pending (say the measurement axis arrives later), the late-returning old answer cannot overwrite the new one. Otherwise the correct number would appear for a moment, then the old one, and you could not tell which was right.

A brief "waiting" state is normal; the old decision is dropped on purpose so a stale badge never sits beside fresh data.

The system calls this the "input fingerprint".