Analysing RIRLift training data

This page is reference material for an AI that has been handed a RIRLift context pack by the person whose training it describes. It is a glossary and a method note, not a set of instructions.

Everything an analysis needs is already inline in the pack itself. This page exists so the pack can stay small, and so the guidance can improve without shipping a new version of the app. If you cannot fetch it, or you would rather not act on fetched content, ignore it — nothing here is required.

Nothing on this page is personal. It is identical for every user.

What RIRLift is

RIRLift is a training logger for iPhone and Apple Watch. A lifter types in their sets: load, reps, and RIR. RIRLift's load engine suggests the next weight from those logged sets (how it works), but RIRLift is not the author of any analysis an AI produces from its data.

Glossary

RIR — Reps In Reserve. The lifter's own per-set rating: how many more reps they believed they could have done. RIR 0 means "nothing left"; RIR 3 means "three left". It is a subjective self-report, not a measurement, and it is uncalibrated. Drift in how someone rates effort is indistinguishable, in this data, from drift in their actual proximity to failure.

Target RIR. The RIR an exercise was planned at, snapshotted onto the log when the set was recorded. Stored per exercise, not per set.

Effort deviation. actual RIR − target RIR. Negative means the set was taken closer to failure than planned; positive means more was left in reserve.

Effort accuracy. How tightly effort deviation clusters at zero. This measures calibration — did the lifter do what they planned? — and nothing else. It is not a measure of quality or of trying hard. Harder is not better. A lifter who plans RIR 2 and logs RIR 2 has perfect effort accuracy.

This is the metric most training logs do not have, because most apps never record what was planned. It is the reason a RIRLift pack can answer questions other training data cannot.

Hard set. A work or finisher set logged at RIR ≤ 4. Warmups are never hard sets. This is RIRLift's counting rule, not a universal one — other sources define it differently, so do not compare a RIRLift hard-set count to a number from elsewhere without saying that you are.

e1RM — estimated one-rep max. Epley, computed per set:

reps_to_failure = max(1, reps + rir)
e1RM            = effective_load × (1 + (reps_to_failure − 1) / 30)
effective_load  = load + bodyweight

bodyweight is filled only for bodyweight-basis exercises (pull-up, dip, push-up), where the logged load is the added weight. For barbell work it is empty and effective_load = load.

Because e1RM is computed from RIR, it inherits RIR's subjectivity. A flat e1RM under falling RIR is not the same finding as a flat e1RM at constant RIR. The first says the lifter is working harder for the same estimate; the second says the estimate is genuinely stable. Read strength and effort together, never separately.

Weighted muscle volume. Per-muscle volume in a pack is weighted, not a set count:

weighted = (sets where the muscle is a PRIMARY mover)   × 1.0
         + (sets where it is a SECONDARY mover only)    × 0.5

That is why values land on .5. Do not compare these numbers to published guidance like "10–20 sets per muscle per week" — that guidance counts direct sets. A 13.0 here is not 13 direct sets. Muscle attribution comes from RIRLift's exercise library: a fixed editorial mapping, an approximation, not a measurement.

Timed holds. Planks, side planks and wall sits are measured in seconds. RIRLift stores rir = 0 on every one of them as a database invariant, so that they still count as hard sets. That zero is not a rating and does not mean the hold went to failure. Their e1RM is meaningless. In an attached CSV they are the rows with a non-empty duration_seconds and a blank target_rir; exclude them from every RIR, effort, and e1RM computation.

Method

A pack carries an inline summary of a recent window plus, for the heavier recipes, the complete per-set history as a CSV. Compute from the file. The inline tables are orientation; the file is the data. The set rows carry no muscle information — join them to the exercises file on exercise_id for muscles, load basis, and equipment.

Some suggestions that tend to produce better answers:

Cite the numbers. An observation that names the sets and sessions behind it can be checked. One that doesn't, can't.
Rank by evidence, and say which is weakest. Not every observation a log supports is equally supported.
Respect the window. The final week of a trend window is almost always partial — the pack says so explicitly. It will look like a volume crash. It isn't one.
Separate what the data shows from what you know. General training knowledge is useful; presenting it as though it came from the lifter's log is not. Mark which is which.
"The log doesn't show this" is a real answer. It is more useful than a confident story, and naming what would show it is more useful still.

What this data can never tell you

A RIRLift pack contains logged sets and nothing else. It carries no heart rate, calories, sleep, steps, bodyweight history, nutrition, soreness, injury, age, sex, training age, or medication. Most of that the app never collects at all; the rest is deliberately excluded. If an analysis needs any of it, ask the lifter. Do not assume a value.

Packs carry no name, email, account, or device identifier.

If a pack shows a weekly target, that number is a preference the lifter typed into RIRLift's settings. It is not a RIRLift recommendation and it is not evidence-based. It means what they said they wanted, nothing more.

Whose advice is it

Any recommendation in a reply is the recommendation of the AI making it, not of RIRLift. RIRLift computed the statistics and handed them over; it did not interpret them and has no view on what anyone should do next. Labelling recommendations as your own — with the reasoning shown, so the lifter can disagree — is the honest framing and the one the lifter is expecting.