Ok, I have no dog in any fight here, but happy to outline my understanding. My professional background has overlap with this kind of thing (like other users here), and if that helps I’m happy to chime in, openly admitting that I have no “inside track”, and could be quite wrong.
All measurements (of anything) have random variations on either side of the supposed true value (often expressed as a “confidence interval”). FTP measurement no different. FTP is even harder, because it’s not a directly measured quantity, but rather inferred from some proxy measurements (such as a ramp, or 40min test).
TR’s recommendation model accounts for this by the fact that they have many measurements in their dataset, and many workouts and resulting gains that they can fit their model to.
The resulting model is the best statistical fit for the data of many users, and predicts what workouts would, on average, benefit a subgroup of users with similar parameters (“Ramp FTP”, “PLs”, age, …) to the user being evaluated.
However, the user being evaluated may differ (in workout performance, or resulting gains) from the average user in that subgroup. Then, the difference between their observed performance and the anticipated performance can be used to predict such discrepancies in future for that user, compared to the subgroup.
I don’t believe TR is trying to accommodate “wrongly estimated FTP” using adaptations. I think TR doesn’t really care about “real FTP” at all. They care about making good recommendations based on the available data. And the available data is Ramp-test “FTP” (plus other parameters like PLs, and observed performance data). So when you provide TR with input parameters for prediction, they should be the same ones TR used to construct their model, imperfect as they may be. Those will deliver get the best predictions from the model, and will minimise the amount of “correction” required, on average.
Some unlucky users will initially get poor recommendations, because they happen to fall in a particularly poorly represented subgroup. They have two options:
- Wait for (and work with) the adaptations system to do it’s thing, while it tunes for their specific case, based on their feedback, and their performance data.
- Manually change their TR (Ramp) FTP input parameter to whatever value they think will deliver more suitable results. Note: the optimal value (the one resulting in optimal gains) is probably not your “true FTP”, and choosing the optimal value is not easy.
I’d recommend option 1, with help from TR support as needed, but if you’re having great success with option 2, obviously keep doing what you’re doing, and kudos!