Guides

Why a nutrition app should say “I don’t know”

The problem, in one example#

You log seven things today. Four of them came from scanned products with a complete record. Three came from a homemade dinner you typed in yourself.

Your sodium total is 568 mg.

Is that a good day? You cannot tell — and neither can the app, unless it tells you that the figure covers four items out of seven. Those three home-cooked items have no sodium data at all, and the dinner might have been the salty part.

568 mg out of four items is a fact. 568 mg presented as the day’s total is a lie of omission.

Why zero is the wrong default#

A missing value has to be treated as something, and the tempting default is zero. It makes the arithmetic simple and the screen tidy.

It also inverts the meaning of your data. Consider what happens as your information gets worse:

What you loggedFibre the app can seeTotal if gaps count as zero
Everything scanned, complete recordsall of ithonest
Half scanned, half typed by handhalf of itlooks halved
Everything typed by handnone of it0 g — looks perfect

The less the app knows, the better your day looks. On a ceiling nutrient like saturated fat or sodium, a day where the app has no data reads as a flawless day. That is not a rounding error, it is the wrong sign.

Where the gaps come from#

Three ordinary places, none of them anyone’s fault:

  • Fibre is not mandatory on European or UK labels. Plenty of products simply do not print it, so a database built from labels does not have it.
  • Open Food Facts is contributed by people. A record exists because someone photographed a packet; they may have captured the energy panel and not the rest.
  • A meal you typed in has no such fields at all. You entered a name, a portion, calories and macros. There was nowhere to put sodium, and the app does not invent it. Neither does an estimate from a photo.

What the app does instead#

SmartCrunch reports coverage — how many of the day’s entries the number was actually computed from — next to the number itself. That is the “known for 4 of 7 logged items” line.

And below 50% coverage it stops showing a total as a number at all. It reads as unknown, because a figure built from under half your food is not a small approximation of the truth, it is a different quantity wearing the same label.

This is also the only honest way to make the ceiling nutrients useful. A sodium figure you can trust to be low is worth having. A sodium figure that is low because the app is blind is worse than none, because you act on it.

The same principle, elsewhere in the app#

It is not a one-off. The same rule shapes the part of the app that matters most: the daily budget.

The engine will not print a maintenance figure derived from your own weeks unless four conditions all hold — enough logged days, enough coverage of the window, a long enough run of weigh-ins, and a result inside a plausibility band. When any of them fails it falls back to an estimate and says which one it fell back to.

The reasoning is the same in both cases and it is worth stating once: a number that nothing supports is not a cautious number, it is a wrong one. And in a calorie tracker the direction of that error matters, because a budget derived from a half-empty diary comes out too low, and too low is the direction nobody notices.

What this costs#

Honesty here has a real price and it is worth naming. An app that always shows a confident total looks more finished. Coverage lines and “unknown” labels look like an admission that something is not working.

The alternative is a screen that is always confident and sometimes wrong, with no way for you to tell the difference. That trade only looks good until the first time it matters.