Adaptive Nutrition Estimation

A recursive estimation system designed to infer maintenance calories (TDEE) from noisy bodyweight and intake data.

What this system does

  • Estimates your maintenance calories (TDEE) based on your real-world progress.
  • Analyzes bodyweight trends using smoothing to filter out daily noise.
  • Updates weekly targets conservatively to avoid overreacting to fluctuations.
  • Provides an uncertainty range based on the consistency of your logged data.

What it does NOT do

  • It is not a replacement for metabolic testing or medical advice.
  • It cannot predict weight change with 100% precision due to individual variability.
  • It does not account for illness, travel, or extreme stress unless reflected in your logs.

How it works: Bayesian Recursive Estimation

Instead of relying on static formulas like Mifflin-St Jeor—which research shows can be significantly off for individuals—Train Libre treats your metabolism as a dynamic "hidden state".

The app uses a Bayesian-inspired recursive estimator (similar to a Kalman filter). Every week, it compares its prediction (based on your intake) with the actual weight trend. It then calculates the "gain"—deciding how much to trust the new data versus the previous estimate.

To handle the "noise" of water retention and glycogen shifts, the system uses a 7-day confirmation rule for goal changes and a phase-dependent scaling factor for energy density (kcal/kg).

Recursive Estimation & Metabolic Smoothing Mechanics

1
Recursive Kalman Filtering
Your metabolic maintenance rate is modeled as a hidden dynamic state xt and estimated recursively. The system transition is governed by xt = xt-1 + wt, where the process noise wt ~ N(0, Q) models metabolic fluctuations.
$$x_t = x_{t-1} + w_t$$
$$\text{where } w_t \sim \mathcal{N}(0, Q), \text{ and } Q = 40$$
2
Observed Maintenance Equation
The daily observed calorie maintenance (Mt) is computed using your energy intake and the derivative of your smoothed bodyweight: Mt = avgCaloriest - (ΔWeightt × kcalPerKgt). We smooth weight scale logs to eliminate daily water retention and glycogen noise.
$$M_t = \text{avgCalories}_t - (\Delta\text{Weight}_t \times \text{kcalPerKg}_t)$$
3
9-Week Linear Energetic Ramp
When starting a diet phase, rapid body mass changes are heavily skewed by non-adipose factors (glycogen depletion, sodium drops). To prevent the estimator from oversteering, the energetic cost of body mass changes (kcalPerKgt) ramps linearly over 9 weeks from a prior-driven 3,000 kcal/kg to the fat-tissue-equilibrium value of 7,700 kcal/kg.
$$\text{kcalPerKg}_t = 3000 + \min\left(1, \frac{t}{9\text{ weeks}}\right) \times 4700$$
4
Handling Missing Data (Q = 40)
On days with missing food logs or weight measurements, the measurement update is bypassed. The state covariance Pt propagates by adding the process noise variance (Q = 40). This increases the uncertainty bounds (Likely Range) in the UI and automatically dampens subsequent updates, preventing sudden weight spikes from distorting your long-term metabolic baseline.

Interactive Bayesian TDEE Calculator

Adjust the inputs below to simulate how daily calorie intake, weight changes, and tracking consistency affect the maintenance estimate and calculation confidence bounds in real time.

2500 kcal
0.00 kg/day (0.00 kg/week)
4 weeks
0 days
Estimated TDEE
2500
kcal/day
Likely Range: 2475 - 2525 kcal (±25)
High Data Confidence
Consistent daily logs have been captured. The recursive filter covariance remains locked (P_t = 100). Estimation is highly reliable.

Uncertainty & Interpretation

Daily scale weight is high-noise data. Factors like sodium intake, hydration, and muscle glycogen can cause shifts of several kilograms that do not represent changes in body tissue.

Trend vs. Noise: The algorithm prioritizes the long-term trend. This means it may feel slow to respond to rapid, short-term changes.
Logging Consistency: The precision of the estimate depends entirely on the consistency of your logs. Sparse data will result in wider uncertainty ranges.
Stabilization: During the first 2-4 weeks, the system relies on profile "priors". It becomes significantly more accurate once it has sufficient user-specific history.

Evidence & further reading