I have been thinking a lot about the recent discussions regarding AI FTP Detection and how the model handles timeframes.
Currently the 28 day detection window acts as a stability guardrail. For most users this makes perfect sense because fitness does not usually jump or crash overnight and preventing users from obsessing over daily fluctuations is good product design.
However for racers or athletes returning from interruptions such as illness, injury, or in my case a corrective surgery that removed a limiter, physiological reality can move much faster than the 28 day window allows the UI to update.
The Problem: The Weather Forecast Analogy
Right now the 28 day prediction feels like receiving a monthly weather forecast.
The first few days are highly accurate because the model knows my recent rides and fatigue. However days 14 through 28 are statistical guesswork. Just like predicting rain 3 weeks out the cone of uncertainty widens massively because life variables like sleep, stress, and missed workouts accumulate.
If I have a breakthrough performance on day 5 such as a race or a Zwift event that smashes my priors the monthly forecast becomes obsolete. But the UI is still locked for another 23 days which forces me to train at an intensity I have objectively proven is too low.
The Request: Two Potential Solutions
1. High Frequency Detection Setting Allow an optional setting perhaps hidden in Early Access to lower the detection window to 7 or 14 days. This would be for users who want to see the volatility and are willing to accept that their FTP might go up and down more frequently. We are providing high fidelity data so letting the model react to it faster would be beneficial.
2. Visualizing Confidence Intervals Instead of a single hard number locked for a month show us the cone of uncertainty. For example it could display Current Predicted FTP 302W plus or minus 5W. As we get further from a verification effort or deep into a block without max efforts the cone could widen. If a user pushes a 20 minute power that pierces the top of the cone it could auto trigger an unlocking of the detection.
Why this helps
It solves the friction between compliance to the plan and the physiology of what the body can actually do today. If the backend model already knows I am riding stronger than the plan predicts giving me a way to officialize that number sooner keeps my training zones relevant and prevents me from having to manually override the system.
Would love to hear thoughts on if a high volatility setting is feasible for the model!