How Flexbound estimates calories without lying to you
Type “chicken burrito” into most macro trackers and you’ll get something like 687 calories. Not about 700. Not 600–800 depending on the tortilla. Exactly 687, a number with three significant figures of confidence and almost nothing underneath it.
Which burrito? Whose database entry? What serving size did it assume? The app knows the number is a guess. It just doesn’t tell you that.
Fake precision is a trust problem
Nutrition estimation is genuinely uncertain. The same dish varies by hundreds of calories depending on portion and preparation. That’s fine. Coaching decisions don’t need perfect numbers; they need honest ranges tracked consistently.
The damage comes from hiding the uncertainty. When users eventually notice the confident numbers don’t add up, they don’t just distrust one entry. They quit tracking.
What honest estimation looks like
In Flexbound, you write your food note the way you’d tell a friend: “eggs and rice, chicken burrito, protein shake.” On Pro, the app estimates it. But every estimate carries three visible things:
- The source. USDA FoodData Central first, then Open Food Facts, then a research-backed web estimate only as a last resort. You can see which one answered.
- The serving assumption. “Assumed 1 large flour tortilla burrito, ~450 g.” If the assumption is wrong, correct it. The value is easy to edit.
- A confidence grade. Computed deterministically from source quality and assumption specificity. A packaged food with a barcode-verified entry reads differently than “some curry.”
Low-confidence estimates are labeled low-confidence. The app is architecturally incapable of presenting a guess as a fact. That rule lives in the decision architecture, not in a style guide.
Your corrections outrank every database
Here’s the part most trackers get backwards: when you correct an estimate, that correction becomes your truth. Next time you log the same meal, your number answers before USDA or anything else. The database serves the log, not the other way around.
Completeness: the switch that protects your TDEE
One more honesty mechanism, and it’s the quiet hero: every day gets a completeness mark. Fully logged? It teaches your adaptive maintenance estimate. Skipped dinner logging? Mark it partial and it’s kept as a note but excluded from the math.
Without this, every half-logged day silently drags your computed TDEE downward, and the app slowly learns you eat 1,400 calories when you actually eat 2,400. With it, incomplete data stops being polluted data.
Why we’ll never “AI” this
A language model estimating your burrito produces a fluent, confident, uncited number. That is the exact failure mode we built this product against. AI in Flexbound writes and explains; it never sets a calorie value. If AI-written prose introduces a number the calculators didn’t produce, the prose is discarded. The full boundary is published here.
Numbers you can interrogate. That’s the product.