Adaptive Training With Wearable Readiness Data

You open your fitness app. It asks you to set up a training schedule. Monday: Push. Wednesday: Pull. Friday: Legs. You dutifully fill it in, knowing full well that by week three your actual training pattern will look nothing like what you entered.

Real life doesn’t follow a spreadsheet. You train Monday, skip Wednesday because work ran late, double up Thursday and Friday, and take the weekend off because the weather was too good to spend indoors. Your “schedule” is a fiction. Your actual training rhythm is something else entirely.

But here’s the deeper problem: even the apps that let you set a perfect schedule still treat every Monday the same. They don’t know you slept four hours last night. They don’t know your HRV crashed. They don’t know you’ve been in a caloric deficit all week. They don’t know that the last time you did heavy legs on a day like today, you couldn’t walk for four days.

We’re building something different.

The Foundation: A Schedule Derived from Data

The first layer of Omnio’s adaptive training system is schedule detection. Instead of asking you to configure your training days, the system analyses 60 days of your actual training data and derives the pattern.

It detects your training type (strength, cardio, hybrid), your split (push/pull/legs, upper/lower, full body), your cardio patterns (primary activities, typical days), your consistency (consistent, semi-regular, irregular), and your sessions per week as a rolling average.

For strength users, it classifies your split by analysing actual per-muscle-group volumes from LiftLog or Hevy data. For cardio users, it tracks which activities you do on which days. The detection uses your real behaviour, not declared intentions.

The most practical output: a next session prediction. For a push/pull/legs user who last trained Pull on Monday, the system predicts Legs as the next session and identifies the most likely day. Confidence levels tell you how reliable the prediction is.

This schedule layer is the base. But a schedule alone isn’t adaptive. What makes a system truly adaptive is what happens between the schedule and the workout.

Layer 1: Personalized Readiness

Most readiness systems use fixed thresholds. Score above 70? You’re good. Below 40? Rest. The problem is obvious: a user whose baseline readiness averages 55 perpetually lives in the “light” zone. A user averaging 85 almost never sees “rest.”

Omnio’s readiness engine computes personalized zone thresholds from your own 30-day readiness distribution. Your “rest” zone is calibrated to your p25 (25th percentile), and your “full” zone starts at your p75. An absolute floor ensures dangerously low scores always trigger rest, regardless of your personal baseline.

The readiness score itself is already multi-source. The platform’s composite readiness score fuses 11 inputs — resting heart rate, HRV balance, sleep quality, HRV variability, RHR trend, temperature deviation, ACWR, and more — sourced from Oura, Garmin, WHOOP, and computed metrics. When a source is missing, weights automatically redistribute. A Garmin-only user gets meaningful readiness without Oura. A WHOOP-only user gets meaningful readiness without Garmin. The engine doesn’t break — it degrades gracefully.

On top of this, the system cross-validates the platform’s composite against each wearable’s own native readiness score. If Omnio says 80 but Garmin says 60, that 20-point divergence is flagged, confidence is reduced, and the system becomes more conservative with its recommendations. When the scores agree, confidence is high and the system leans into its prescription.

Layer 2: Biometric Safety Gates

The composite readiness score blends many inputs into a single number. That’s powerful for the general case, but it has a weakness: a dangerously suppressed HRV can be diluted by other inputs that look normal. You could get a “full training” recommendation while your HRV is screaming “stop.”

Omnio adds independent biometric gates — hard overrides that can force zone demotions regardless of the composite score:

HRV gate — If today’s HRV is more than 2 standard deviations below your personal baseline, training is blocked. 1-2 SDs below? Light training only. The composite score becomes irrelevant when a single critical metric is this far out of range.
RHR gate — If your resting heart rate is significantly elevated above your baseline (a classic early-overreaching signal), the gate triggers a caution or block.
Sleep gate — Very poor sleep (below your personal 10th percentile) blocks full training. Poor sleep (below your 25th percentile) triggers caution.

These gates are safety rails. The composite handles the common case well. The gates handle the edge case where one metric is dangerously off while others mask it.

Layer 3: Recovery Intelligence

Knowing you need rest is one thing. Knowing when you’ll be recovered is another.

Omnio learns individual recovery curves for each muscle group. By tracking how your HRV and readiness change in the 1-4 days after training each body part, the system builds a personal recovery profile. Maybe your legs take 2.5 days to recover. Maybe your upper body recovers in 1.5. That’s not something a generic model can predict — it’s learned from your data.

This feeds a recovery forecast: a 5-day projection of your predicted readiness. Open the app on Monday after a hard leg session, and you’ll see that Tuesday is predicted as light-only, Wednesday returns to full readiness, and Thursday (your scheduled pull day) looks green. The forecast uses your personal recovery curves when available and falls back to population defaults for new users.

Recovery curves also enable smarter session swapping. If today’s planned session targets a muscle group you trained yesterday and your personal data says you typically need 2.5 days to recover it, the system can suggest swapping to a different muscle group instead of blindly following the rotation.

Layer 4: Readiness-Gated Workout Adaptation

This is where the system stops being an advisor and starts being a coach.

Your training plan is a rotation — Push, Pull, Legs — not a calendar. When you ask “what should I do next?”, the system resolves the next session in your rotation, checks if the target muscle groups have recovered, and passes the result through the adaptation engine. The engine applies a hierarchy of rules:

If your zone is “rest” or a biometric gate is blocking: Session is replaced with mobility and light movement. No negotiation.

If your zone is “light” or a gate is at caution: Volume is significantly reduced. RPE is capped well below max effort. Isolation exercises are dropped — you keep the compounds. If the target muscle group was recently trained and your recovery curve says it hasn’t recovered, the session is swapped to a different group.

If your zone is “full” but ACWR is in the danger zone: Volume is moderately reduced and intensity is capped. The rationale: you’re recovered enough to train, but your recent load spike means this isn’t the day to push for a PR.

If your zone is “full” and ACWR is optimal: Session is delivered as prescribed. No modifications.

If your zone is “full” and ACWR is low with an improving trend: Progressive overload kicks in. Volume increases gradually. This is where growth happens — the system recognises that you’re recovered, your load has room to grow, and your trend is pointing up.

If it’s a scheduled deload week: Volume drops substantially across all sessions. RPE is capped at low effort. Exercise selection stays the same — you’re still practising the movements, just at reduced intensity.

Every adapted workout includes a clear explanation of what changed and why. “Volume reduced — HRV is well below your baseline” is more useful than a vague yellow circle.

Layer 5: Nutrition-Aware Training

No competitor integrates nutrition data into training adaptation. They track macros in one silo and workouts in another. Omnio connects them.

If you log nutrition (via MyFitnessPal), the system computes your nutritional status and feeds it into the adaptation engine:

Severe caloric deficit → volume and intensity are capped aggressively. Recovery capacity is significantly impaired in a large deficit — pushing volume here is counterproductive.
Mild caloric deficit → volume is moderately reduced. A lighter restriction that acknowledges the trade-off between training stimulus and recovery.
Low protein intake → advisory note: “Protein intake is below target. Prioritize a protein-rich meal within 2 hours post-workout.” The system doesn’t block training for low protein, but it makes sure you know.
Very low carbohydrate availability combined with a high-intensity prescribed session → pre-workout nutrition warning. Glycogen-depleted high-intensity work underperforms and increases injury risk.

These nutritional modifiers stack with readiness gates. A light-zone reduction combined with a deficit-based reduction compounds multiplicatively. The system respects the reality of impaired recovery from multiple directions simultaneously.

The recovery forecast adjusts too. In a large deficit, your predicted recovery rate slows meaningfully. The forecast honestly shows that Thursday’s session might need to be light because you won’t have recovered as fast as usual while undereating.

Layer 6: The System Learns (Bayesian Personalisation)

Everything described above is the forward pass: data in, recommendation out. But a system that doesn’t evaluate its own recommendations isn’t truly adaptive. It’s just rules.

The final layer closes the feedback loop — and it does so with Bayesian inference, not ad-hoc nudges.

Six Independent Sub-Models

The learning system isn’t one monolithic model. It’s six independent Bayesian sub-models, each learning a specific parameter about you:

Recovery Curve — How fast do you recover after sessions of varying intensity? The prior starts at population averages from sports science. A fast recoverer converges well below average. A slow recoverer converges above it.
Volume Tolerance — What’s your minimum effective volume, maximum recoverable volume, and maximum adaptive volume per muscle group?
RPE Calibration — When the system prescribes RPE 7, what intensity does that actually correspond to for you?
Readiness Prediction — Given tonight’s sleep, today’s HRV trend, and recent training load, what will your readiness be tomorrow morning?
Schedule Preference — When do you actually train? (Not when you say you will.)
Nutrition Impact — How does your caloric balance affect your personal recovery rate?

Each sub-model starts with a population prior — the best estimate from sports science literature for someone like you (age, sex, training level). As your data accumulates, the prior is updated via Bayes’ rule into a personalised posterior that converges toward your actual physiology. The math guarantees that with zero data you get reasonable defaults, with a few weeks of data you get useful personalisation, and the estimate never jumps wildly from a single noisy observation.

Outcome Tracking

Every prediction the system makes is logged with a measurable target:

Recovery curve predicted 28 hours to HRV baseline → actual was 34 hours → error: +6 hours
Readiness prediction said 72 tomorrow → actual was 65 → error: -7 points
RPE calibration predicted RPE 7 → user reported RPE 8 → error: +1

Each sub-model has a defined success threshold appropriate to its domain. The system tracks whether it’s beating a naïve baseline — for readiness, the baseline is simply “tomorrow = today.” If the Bayesian model can’t beat that, it’s turned off and the rule-based system from Layers 1-5 takes over.

Confidence-Gated Predictions

The system doesn’t blindly trust its own models. Every prediction comes with a confidence score derived from the width of the posterior distribution. Narrow posterior = confident. Wide posterior = uncertain.

If confidence is below the activation threshold, the model’s prediction is discarded and the rule-based fallback is used instead. You see the same good recommendations from Layers 1-5. The Bayesian layer only takes over when it has earned enough confidence through data.

This means new users get the full rule-based system immediately — no “training the AI” period where recommendations are bad. The learning layer is invisible until it has something useful to contribute.

Safety Envelope

No model can violate hard physiological safety bounds, regardless of what it learns:

Maximum sets per muscle group per week
Capped weekly volume increases
Mandatory rest days
Consecutive training day limits
Periodic mandatory deloads, even if all metrics look fine
Biometric hard stops: body temp elevation, severe RHR elevation, critically low sleep

The model can learn anything it wants within these bounds. Outside them, the output is clamped.

Exploration

A system that only observes outcomes from its own prescriptions develops confirmation bias. If it always deloads when readiness drops below 60, it never discovers that you perform fine at 55.

Occasionally, the system deliberately deviates slightly from the “optimal” prescription — a bit harder or a bit softer — to discover your true boundaries. Exploration only happens when confidence is moderate (not too low, not too high), never in the rest zone, never on consecutive sessions, and always within the safety envelope. The outcomes are tracked separately so the system knows whether exploration was informative.

Drift Detection

Bodies change. You get fitter, you get injured, you age, you change your sleep habits. A model trained on six months of data from a different version of you isn’t helpful.

Every sub-model is continuously compared against its naïve baseline. If a model’s recent accuracy drops significantly below the baseline, it’s automatically reset to the population prior and starts learning again. If it’s only slightly worse, the system increases the recency weighting so newer observations matter more. Models that are healthy and beating their baseline are left alone.

The Result

The longer you use the system, the more accurate it gets. Your recovery predictions, volume prescriptions, readiness forecasts, and RPE targets all converge toward your individual physiology. Week 1 uses population priors. Week 4, the posteriors start narrowing. By week 12, the system has a confident, personalised model of you — with quantified uncertainty on every prediction.

How It All Fits Together

A concrete example. You open the app ready to train:

Your rotation queue says Push is next (you did Legs last session, Pull before that).
The resolver checks your chest recovery — you last trained push 3 days ago, and your personal recovery curve says chest needs 2.3 days. Recovered. Push is confirmed.
The composite readiness score is 68, computed from last night’s HRV (slightly below your baseline), decent sleep (7.2 hours, 22% deep), and normal RHR.
Your personalized zone thresholds put this in the “light” zone (your p75 is 73).
The HRV gate fires at “caution” — HRV is 1.3 SDs below your 14-day baseline.
ACWR is 1.1 (optimal zone). No load concern.
Your nutrition status shows a mild caloric deficit (averaging 300 kcal below TDEE this week) and protein is 10g below target.

The adaptation engine produces:

Push (Adapted — Reduced) Volume: significantly reduced (light zone + mild deficit stacked) RPE cap: low effort Exercises: Bench Press 3×8, Incline Press 3×10 (isolations dropped)

HRV is below your baseline. Mild caloric deficit this week. Protein is slightly under target — aim for a high-protein meal post-workout. Forecast: readiness expected to return to full zone within 2 days for Pull.

Notice what’s absent: no mention of what day of the week it is. The system doesn’t care whether it’s Tuesday or Saturday. It cares about your rotation position, your recovery state, and your readiness. That’s six layers of context producing a single, specific, explained recommendation. No other consumer platform does this.

What Makes This Different

The design philosophy: derive, don’t declare. Gate, don’t guess. Explain, don’t dictate.

Zero onboarding friction. Connect your devices. The schedule, readiness zones, and recovery curves emerge from your data. No setup wizard, no questionnaire.
Automatic adaptation. Everything recalibrates continuously — your schedule, your zone thresholds, your recovery curves, your volume tolerance. Shift from a 4-day split to a 3-day split? The system catches on within a couple of weeks.
Honest reflection. You might think you train 5 days a week. The data says 3.2. You might think you recover fine on 6 hours of sleep. Your HRV data says otherwise. The system reflects reality, even when reality is inconvenient.
Explainable recommendations. Every modification comes with a reason. “Volume reduced because HRV is 1.5 SDs below baseline” is actionable. A generic yellow circle is not.
Works for everyone. Powerlifters with strict PPL rotations, runners logging 40 miles a week, hybrid athletes who lift and cycle, casual gym-goers with irregular schedules — the same engine handles all of them because it’s adapting to data, not fitting behaviour into templates.
Self-improving. The system evaluates its own accuracy, adjusts parameters that aren’t working, and gets more personalised with every week of data. This is the retention moat — the app literally gets better at coaching you the longer you use it.

Honest Limitations

Nutrition integration requires logging meals via MyFitnessPal. If you don’t log food, the nutrition layer is simply skipped — no penalty, no broken recommendations, just one fewer signal.
Recovery curves need several weeks of combined training and HRV data before the Bayesian model’s posterior narrows enough to meaningfully personalise. Before that, population priors are used — they’re reasonable but impersonal. Some models personalise faster than others — it depends on how much signal they need and how often they get observations.
Strength split detection requires muscle-group-level data from LiftLog or Hevy. Total-volume-only logging gets training type and consistency but not split classification.
New users need 2-3 weeks of data before the schedule detection activates and 14+ days before personalized readiness thresholds replace the defaults. Better to show nothing than show something wrong.
Highly irregular trainers will get classified as “irregular” with no typical days. That’s accurate, not a failure — the system is reflecting reality.
Subjective readiness (how you feel, not what your wearable says) is captured via a pre-workout check-in. Four sliders, 10 seconds. This fills the gap between wearable data and lived experience — DOMS, stress, motivation — that no sensor can detect. Per-muscle-group soreness feedback is available optionally for users who want to refine recovery curves further — but the system works fully without it.
The learning models need data to personalise. New users get the full rule-based system (Layers 1-5) immediately. The Bayesian layer only activates when its confidence exceeds a threshold — if it can’t beat a naïve baseline, it stays off. You’ll never get a worse recommendation because the model is still learning.

Technical Details (for the Curious)

The schedule computation is a pure function — no I/O, no database calls, just math on a list of daily records. It runs in under 10ms on a 60-day window. The readiness composite fuses 11 inputs via a weighted scoring engine with automatic weight redistribution when sources are missing, computed in dependency order (readiness depends on sleep score, which is computed first). Biometric gates are independent SD-based deviations from personal baselines with 7-14 day rolling windows. Recovery curves are learned per muscle group by tracking post-training HRV and readiness deltas across 60-90 days, cached with a 72-hour TTL. The adaptation engine is a priority-ordered rule set operating on a frozen context snapshot — deterministic, testable, and explainable.

The Bayesian learning layer uses conjugate Normal-Normal models for continuous parameters — closed-form updates, no gradient descent, no GPU. Each sub-model uses recency-weighted observations so the system naturally adapts to concept drift without explicit retraining. Confidence intervals are analytically derived from the posterior variance. The entire learning pipeline runs on the same Python/VictoriaMetrics stack as the rest of the system.

Everything is source-agnostic. The same architecture works whether you wear an Oura ring, a Garmin watch, a WHOOP band, or any combination. Add a new wearable source, and it automatically contributes to the composite without any changes to the adaptation logic.

Omnio is a health analytics platform that unifies wearable and health data with AI-powered insights. Learn more at getomn.io.