Adaptive Training Engine Notes

For the MVP, the most useful inputs are the ones users can actually provide or validate: stated goals, training background, available days, equipment context, completed sessions, perceived effort, and light recovery signals such as soreness or general fatigue. These are less glamorous than wearable streams, but they are enough to build a sensible adaptive loop.

Later integrations — Apple Health, Apple Watch, Garmin, calendar data — can sharpen the context, but they shouldn't replace the visible core logic. Device data can improve judgement about load and routine, but the plan still needs to read like something a thoughtful coach would recommend, not the output of an optimiser.

Progression should be gradual, mode-aware, and constrained. A strength progression should account for movement quality and consistency, not just completed volume. A running progression should respect recent load and recovery before it increases distance or intensity. Mobility and balance work should support the rest of the system, not disappear because they are harder to quantify.

• Increase load when adherence is steady and recovery signals are stable.
• Hold steady when life is busy but the current structure is still manageable.
• Reduce or redistribute work when fatigue, missed sessions, or scheduling friction suggest the plan is outrunning the user's capacity.
• Preserve continuity where possible so changes feel like refinement rather than reset.

A lot of adaptive systems fail at the explanation layer. The changes might be perfectly reasonable, but the user never finds out what changed, why, or what to expect next — and that's a quieter problem than it sounds. They stop learning from the system. They just receive plans.

Hoxa should explain adjustments in plain language. If a long run moved, say why. If a recovery session replaced a harder day, say that directly. The goal is to help users build a better mental model of their own training, not just personalise outputs behind the curtain.

There are predictable ways adaptive products become less useful. They overreact to a small number of misses. They optimise for completion at the expense of progression. They become so protective that the plan never gets meaningfully harder. Or they become so aggressive that users stop trusting the guidance. Good adaptation is a balancing act, not a constant intervention.

The bar for Hoxa is narrower than the category often suggests. The engine doesn't need to behave like an oracle. It needs to get reliably good at adjusting plans for ordinary human variability, and explain itself when it does. That alone would be a real advantage.