5/3/1 and RP need different logs. Generic apps give you one.
Every structured program computes its verdict from a field the standard sets-times-reps-times-weight entry never had room for. Here's what each one throws away.
The one number a generic log throws away
Three cycles into 5/3/1, the only figure that decides whether the program is working is the rep count on the AMRAP set. A lifter running Boring But Big hits the top set, grinds out eight reps at a weight the sheet says should give five, and that eight is the verdict: the training max has room, next cycle climbs. Then the log stores it as set 3, 8 reps, 245 lb, identical in shape to a warm-up single, and the one datum that mattered dissolves into a wall of rows that all look the same. The session got captured. The signal didn't.
The discarded field
Every structured program runs a hidden calculation, and it reads from one or two fields to decide whether you keep moving or reset. Call it the discarded field: the datum the program's own logic depends on, and the one a generic template has no column for. 5/3/1 reads the AMRAP reps. RP Hypertrophy reads RIR and weekly volume per muscle. GZCLP reads the exact point a linear jump fails. None of those live inside sets times reps times weight. So the app records everything and preserves nothing that answers the only question worth asking a training log: is this working, and if not, why.
A log isn't a storage problem
Most tracking apps treat logging as a storage problem. Get the numbers in fast, sort it out later, and the interface that wins is the one with the fewest taps between set and saved. Speed matters, nobody's arguing for slower entry. But the fast-generic entry optimizes the wrong verb. It's built to record a workout, not to read a program, and those aren't the same job. A program is a hypothesis with a decision rule bolted on, and the decision rule needs its inputs logged at the resolution it operates on. Drop below that resolution and you've got a diary where you needed an instrument.
What each program actually measures
Line the three up and the pattern is hard to miss: each carries its verdict in a different field, and the standard entry is the exact intersection where all three lose it. The weight and the rep total survive in every case. The thing that decides whether the block worked does not.
Program
What decides progression
The field the log must carry
What sets x reps x weight loses
5/3/1 (Wendler)
e1RM trend across cycles
AMRAP reps on the plus set
The rep count that separates a warm-up single from the verdict set
RP Hypertrophy
MRV proximity
Per-set RIR + weekly sets per muscle
RIR entirely; per-muscle volume unless you hand-sum every movement
GZCLP (Lefever)
Linear-progression failure point
Which rep-scheme stage failed, and when
The ladder position, so the reset decision lives only in memory
The field each program's decision rule reads from, and where a generic entry drops it.
5/3/1: the AMRAP set is the instrument
In Wendler's 5/3/1, the training max sits at 90 percent of your true max, and every week's final set is an AMRAP, the '+' set. The reps you hit there feed an estimated 1RM, the Epley figure of reps times weight times 0.0333 plus weight, and the trend in that estimate across cycles is the entire progression signal. Beat last cycle's reps at the next weight and the training max is honest, so it climbs its scheduled 5 pounds up top, 10 on the lower lifts. Stall on the plus set two cycles running and the max was set too high, so it's reset time. Strip the rep count off that one set and you can't compute a single e1RM. You kept the weight. You lost the verdict.
RP Hypertrophy: RIR and volume, counted per muscle
Renaissance Periodization's hypertrophy model runs on volume landmarks, MEV, MAV, and MRV, and it decides everything by where your weekly sets per muscle sit against those and how your reps-in-reserve trend across the mesocycle. Early week, three to four RIR and moderate volume. Later weeks, RIR falls toward zero as sets accumulate, and the block ends when you're brushing your maximum recoverable volume. To see any of that, the log has to tally sets by muscle group per week and carry a per-set RIR. A generic entry logs neither cleanly: RIR has no field, and reconstructing 'chest volume this week' means summing across every pressing movement the app filed under a separate exercise name. The MRV read, the thing the whole program pivots on, isn't recoverable after the fact.
GZCLP: the failure point is the data
Cody Lefever's GZCLP progresses linearly until it can't, and the whole method is about logging the can't precisely. A T1 lift runs 5x3 with an AMRAP last set: complete it, add weight. Miss, and you drop to the next scheme, 6x2, then 10x1, and only when you fail 10x1 do you retest a 5-rep max and restart the ladder. The reset decision depends entirely on knowing which stage you failed at and when. A standard log stores the weight and the reps but not 'this was a failed 6x2 at stage two,' so the ladder position, the single piece of state GZCLP needs, lives only in your head. And your head is exactly what a log exists to replace.
Five years of rows that can't testify
Here's what compounds. A generic log will happily hold a decade of sessions, and lifters point at that volume like it's an asset. On its own, it isn't. Predictive value comes from resolution on the axis the program cared about, not from row count. If your 5/3/1 years never stored AMRAP reps, no query can tell you which training-max jumps you earned and which you forced. If your RP blocks never carried per-muscle volume and RIR, you can't see which muscle groups you chronically under-stimulated. The data's all there and none of it can testify. That's the quiet cost: not a lost workout, a lost explanation, found years later on the day you finally go looking for one.
A logged workout and an auditable program are different things
The gap doesn't show up on session day. It shows up years later, the first time you ask your history *why* a block worked, and the log was never built to hold the answer.
An instrument reads the program, not just the set
Which is the whole case for logging that knows what program you're running. When the app understands a set is a 5/3/1 plus-set, it stores the AMRAP reps as the load-bearing field and shows the e1RM trend across cycles without you doing arithmetic in the parking lot. When it knows a block is RP-style, it tallies volume by muscle and keeps RIR as first-class data, so MRV proximity reads as a chart instead of a guess. When it's tracking GZCLP, it holds the ladder position and flags the reset the session it's actually due. Platepusher is built on that stance: log the field the program decides on, surface the verdict, stay out of the way. No coaching, no prescriptions. It just refuses to discard the number that mattered.
See what program-aware logging keeps that a generic log throws away. Get Platepusher.
The reader here has run at least one of these programs long enough to know a generic log loses the signal. Platepusher stores the program-specific field, the AMRAP reps, the per-muscle volume and RIR, the GZCLP ladder stage, so a multi-year history can actually explain itself instead of just piling up.
