The measured burn engine

Standard TDEE calculators guess from stats, and two identical-looking people can burn hundreds of calories apart. Starting targets from a guess is fine; keeping them there is coaching malpractice once real data exists.

FuelPath measures instead: the client's own food log and weigh-ins tell you what their body actually does.

Over a rolling 28-day window: average logged intake, minus the weight trend converted to calories (a pound is about 3,500), equals measured daily burn. Eating 2,400 while losing half a pound a week means burning about 2,650.

Only credible days count (800 to 6,500 kcal logged), and the engine needs enough logged days and weigh-ins spread across the window before it trusts itself; until then it shows warming up. Consistent under-logging cancels out of the math, which is why the number beats any wearable's calorie guess. Wearable calories are deliberately ignored.

Each phase's anchor comes off the measured burn. Fuel holds at it, Build adds a surplus sized for about 0.4 lb a week, and Cut takes a deficit sized against the client's fat stores where composition allows it and a percentage where it does not. When a client's saved target drifts from their anchor, the gap shows on their page and the expenditure dashboard, with an apply button and a line saying what set the number.

Applying moves the anchor, and all three phases are rebuilt from it together. That matters more than it sounds. Before, a coach could nudge a client's Fuel in September and leave their Cut sitting on a July calculation, so the client walked into a cut that was higher than the phase they just left. Three targets derived from one number are always in the right order, so that cannot happen now.

Applies move in steps capped at 250 calories so a thin data window can never crash someone's intake, and a red checkbox makes you acknowledge thin data before applying. There is a second button to travel the whole distance in one move when a client is a long way off and their measurement is solid; it is deliberately hidden on a thin window. Every change is audit-logged and reversible with Undo on the athlete's Macros page.

You do not have to watch for the moment their engine wakes up. FuelPath notifies you twice: once when a client's burn first becomes readable (roughly two weeks of logging and weigh-ins), and again when the window is solid enough to set targets from without the thin-data tick (roughly a month). Both land as a notification and a Needs Attention flag, and both link straight to their expenditure breakdown. The targets they started with came from a calculator; these are the two moments to replace them with measured ones.

Opening a client leads with the same read: a Macro review card with their target, the measured anchor, and the gap, louder past 250 calories. It also separates the two problems that look alike. Eating to plan with a big gap means the target is wrong; averaging well off their own number means the gap is adherence and a conversation beats a recalculation. Changing that phase's macros clears the card.

You do not have to go looking for any of this. Overnight, FuelPath checks every client whose burn is readable and puts the ones that have drifted in a Macros to look at list on your Clients page, showing the reason, all three phases before and after, and how good the measurement behind it is. Nothing changes until you approve it, and the record names you, not the app. A client whose numbers anybody touched in the last week is left alone, so a step you approved today does not come back tomorrow asking for the next one.

The queue stays quiet on purpose. If it raised something for the whole roster every week you would clear it without reading, which is the same as not having it. Read the reason line before you tap, and when the measurement is thin the card says so and tells you to look at their logging first.

Cut stalled with a ready engine: trust the measured number over the calculator, apply the anchor step, and hold for two weeks before judging.

Build stalled: same move upward; the surplus only exists relative to measured burn. Engine warming forever: the client is not logging or weighing enough, which is a compliance conversation, not a math problem.

Client one-liner when they ask why targets moved: your own data showed your burn, so your plan now matches your body, not a formula.

The measured burn is a four-week average, so it already pays for a client's ordinary training. What it cannot see is one day far above that average. Training fuel adds only that difference to the day, as carbs, and the client sees it as the lighter green slice after the notch on their calorie and carb rings.

The math, so you can explain it: the session's energy (device calories trimmed 15 percent, or an estimate from sport, time, and distance), minus what they would burn sitting, minus their average training day. Example: a client whose usual day carries 230 kcal of training runs 88 minutes for a net 830. The day gets about 600 extra, against the roughly 200 a manual refeed would have given.

Easy days hold back a small reserve (capped at 200) that big days spend, so the week still matches the burn. Without it, a client who trains unevenly would be over-fed every week by the sum of their big days.

Planned sessions fuel the day before a long one (1 g/kg of carbs, 2 for a race) and the day itself, then switch to the watch's numbers when it syncs. The Training fuel card gives during-session carbs (30 to 60 g an hour as sessions lengthen) and a recovery top-up.

Your controls: the Manage tab switch turns training fuel off per client if you would rather set big days by hand, and a manual refeed never stacks with a session (the bigger wins). Long run days no longer read as over plan on your roster; adherence is judged against the bigger target.