Why Tab Never Lets AI Invent Calories

Recognition is not nutrition analysis

A model looking at a picture can make a plausible statement about what it sees. That is valuable for naming rice, salmon, greens, or a sauce and proposing portions. Plausibility is not the same as a measured nutrient result. The image does not contain a nutrition label, a recipe, or the chemical composition of the food. Asking one model to identify the food and invent a complete calorie total hides several decisions inside a single number that a person cannot inspect.

Tab draws a hard boundary between those jobs. The recognition response has places for food identity, preparation clues, estimated grams, confidence, and possible extras. It has no nutrient fields. The next stage matches those descriptions to food records. Only then does the system calculate calories, protein, carbohydrate, fat, and available micronutrients from the portion. That boundary is an engineering control, not a marketing phrase, and it applies to scanned plates and recipe calculations.

Evidence for this section: Nutrients via PubMed Central

Grounded numbers have a repair path

USDA FoodData Central publishes nutrient values and portion information for multiple food datasets. A typical calculation starts with a nutrient value per 100 grams and scales it by the selected edible weight. If 120 grams was estimated but 180 grams was eaten, the correction is explicit. If the wrong chicken preparation was selected, the food record can be replaced. Each edit has a predictable effect because the nutrient values are attached to a record rather than generated anew.

This makes disagreement productive. “That total looks high” becomes a short checklist: inspect which foods were selected, their gram amounts, their preparation, and any additions. A model-generated total cannot explain whether it imagined a larger portion, a richer recipe, or a different food. It may produce a confident explanation after the fact, but that explanation is not a source record. Tab instead shows the assumptions that actually produced the saved number.

Evidence for this section: USDA FoodData Central

Databases still require judgment

Grounding does not mean every database row is automatically right for every plate. Foods vary naturally, branded products change, recipes differ, and datasets have different collection methods. Search can also select the wrong identity when names overlap. “Roasted chickpeas” should not become a chicken product because the words look similar. Good matching must respect the primary food, preparation state, and unexplained ingredients, then expose uncertainty when the match is weak.

Tab therefore treats entity resolution as part of accuracy. It ranks candidate foods, checks important terms, and preserves an estimated status when a component cannot be matched confidently. An unmatched component must not disappear or silently contribute zero, because omission can make an incomplete plate look precise. A visible estimate is honest about uncertainty and gives you a chance to select a better food before the entry becomes part of your history.

Evidence for this section: USDA FoodData Central · USDA Agricultural Research Service

Consistency matters as well as traceability

Generated nutrition may change when the same prompt is phrased differently or the model version changes. A grounded calculation is stable once food identity and portion are fixed. The vision estimate may still vary slightly between images, but a 5 percent portion change is easier to understand than an entirely reimagined nutrient profile. Stable calculations also make regression testing possible: known food records and portions should continue to produce the same totals after unrelated app updates.

For the person logging, stability means saved meals remain useful. When you correct a breakfast to the products and portions you normally eat, that meal can become a repeatable shortcut. You do not need the camera to reinterpret it every morning. The app should earn trust by remembering verified choices, showing when it is uncertain, and letting you choose another input method when a label, recipe, or scale gives stronger evidence.

What this promise does—and does not—mean

“Never lets AI invent calories” means nutrient values are not accepted from the recognition model. It does not mean every scan is exact, every database food perfectly represents your meal, or every portion estimate is correct. Those would be unsupported promises. The practical benefit is narrower and more useful: the number is tied to a named food record and a portion you can review. Accuracy can improve through correction because the system reveals what needs correcting.

The same separation also makes maintenance safer. A food-database update, matching change, or recognition-model update can be evaluated independently against known examples. Developers can inspect which record and portion produced a result instead of comparing two unexplained model answers. Users get the same advantage at meal scale: a correction changes a visible assumption. This does not remove uncertainty from food composition or portion estimation, but it prevents uncertainty from being hidden inside a nutrient value that has no identifiable source.