A training app that tells you to squat 102.5 kg is only useful if you can find out why. Without the rule behind it, a recommendation is a number you either trust or ignore, and most lifters end up ignoring it by about week three.
So here is the whole decision, written out. Not a description of the philosophy: the actual rules, the actual thresholds, and the order they run in. You should be able to predict what IronLedger will suggest next week before next week arrives. If you can't, the feature has failed at its job.
Why a rule instead of a model?
The obvious thing to build in 2026 would be an AI coach. Feed the log to a model, ask it what to do next, render the answer. Several apps do exactly this.
We didn't, for one reason: you cannot audit it. If a model tells you to squat 102.5 kg and you ask why, the honest answer is that a very large function returned that number. You cannot check it. You cannot predict it. And when it produces something odd on a bad week, you have no way to tell whether it understood something you didn't or simply made a mistake.
A rule has none of that ambiguity. You can do the arithmetic in your head while you load the bar. That matters more than it sounds: a rule you can predict is a rule you can plan around, and a rule you can plan around is one you will actually follow when the session is hard and the plates are already on.
The tradeoff is real and worth stating. A deterministic rule will not notice that you've had three bad weeks in a row because of something outside the gym. It doesn't infer. It applies what it's told to a history you gave it, and it tells you which part it used.
The three rules
1. Linear load
The blunt one, and correct for most of a beginner or intermediate block. If you hit the prescribed reps, add a fixed increment. The default is 2.5 kg.
It's blunt on purpose. For a lifter who is genuinely adding weight every session, anything cleverer is noise.
2. RPE/RIR hold-advance
The rule that stops one hard day compounding into a missed week. It watches reported effort against two thresholds and decides whether to advance, hold, or (if configured) back off.
Using IronLedger's defaults:
| Last session reported | What happens next |
|---|---|
| RPE 7 or below, or 3+ RIR | Increase by the increment |
| RPE 8 | Hold the load |
| RPE 9 or above, or 0 RIR | Hold the load |
| Prescribed reps missed | Hold, or decrease if the rule says so |
Two details worth knowing. When several sets are logged, the engine takes the highest RPE and the lowest RIR across them, so the hardest set governs the decision rather than an average that would flatter a session. And if you logged no effort values at all but hit the prescribed reps, it treats that as a clean session and increases.
3. Percentage of training max
Used by percentage-based programs like 5/3/1. Rather than reacting to last session, it computes a percentage of your training max.
Training max is 90% of your estimated 1RM, rounded to the nearest 2.5 kg. The estimate uses the Epley formula:
estimated 1RM = weight × (1 + reps ÷ 30)
100 kg × 5 reps → 100 × (1 + 5/30) = 116.7 kg
training max → 116.7 × 0.9 ≈ 105 kg
Estimated 1RM is a trend signal, not a prediction of what you'd hit on a maximal attempt. If the number jumps because you logged a heavy triple for the first time in a month, that jump is arithmetic, not adaptation.
That choice usually mirrors a bigger one: whether your block runs a linear structure or a daily undulating (DUP) rotation with a different target most sessions. See DUP vs linear periodization for which rule pairs with which model, and what the research says about the strength difference between them.
The order they run in
The rules don't compete. The engine checks in a fixed order and stops at the first match:
- Manual override. If you set a weight yourself, that wins. Always.
- Deload week. If the week is flagged as a deload, reduce conservatively (default 90%) and stop.
- Percentage rule, if the program uses one.
- Otherwise, the linear and RPE/RIR path, which share an implementation.
Inside step 4 the checks are also ordered: no history yet, then reps missed, then effort too high, then effort low enough to advance. Anything that doesn't match holds the load. Holding is the default outcome, which is deliberate: when the engine is unsure, it should not add weight.
Reading the reason line
Every recommendation carries a sentence that stands alone. If you read only that line, you should be able to reconstruct the decision. It names three things:
- What happened last time, as logged values rather than a judgement
- The rule applied, named the same way everywhere else in the app
- The threshold it was watching, so you know what would change the answer
In practice that reads like "Last session RPE 9 at 100 kg, holding load" or "Last session hit all prescribed reps, increasing squat by 2.5 kg." No hedging, no personality, no encouragement. It's a log entry, not a coach.
Overriding it
The engine is advice. If your judgement disagrees, change the number.
When you do, IronLedger labels the set as a manual override and keeps its own suggestion visible beside it. That's not a nag. It's so next week's rule still has clean inputs, and so you can see later whether your override or the rule was closer.
One thing the app will never do is quietly rewrite a set you logged. A logged set is a record of something that happened.
How we know it behaves
The engine has a test suite covering the rule paths, and it runs on every commit. That's a low bar and worth being honest about, but determinism is what makes it possible at all: the same input always produces the same target, so the behaviour can be pinned to a specific expected number rather than a range.
That property is the whole argument for building it this way. You cannot write a test like that against a model.
Frequently asked questions
No. The progression engine is a deterministic rules engine, not a large language model. The same logged sets always produce the same target, and every recommendation shows the rule and the reason behind it.
The short version
Three rules, published thresholds, a stated order, a reason on every target, and an override that the engine respects rather than argues with.
You don't have to trust the app. You can check it. That was the point.
Read more on progressive overload tracking, RPE versus percentage-based training, and how to structure a deload.
Keep learning
