How we count — including the parts that can go wrong.

The AI names the food. The database does the arithmetic.

When you describe or photograph a meal, the AI does one job: decompose it into ingredients with gram amounts. "Spaghetti bolognese" becomes 150 g cooked spaghetti, 120 g ground beef sauce, 10 g parmesan. That is genuinely what large models are good at — recognizing food and judging portions.

The nutrition numbers for each ingredient are then looked up in USDA FoodData Central, the U.S. government's food composition database. The AI never supplies a number the database has.

The portion is the larger source of error, and it is treated as one. When you say how much — “2 large eggs”, “a slice of bread”, “6 oz steak” — the grams come from USDA’s own serving weights or from the weight you gave, not from the model. Only when nobody said how much does the model’s estimate stand, and the entry says so.

7,600+ foods, verified on import.

We use two USDA datasets — SR Legacy and FNDDS (the 2024-10-31 release), all public domain. Energy comes from USDA nutrient 1008, "Energy (kcal)", which uses Atwater specific factors rather than the rougher 4/4/9 rule.

On import we recomputed energy for every food from its protein, carbohydrate and fat — 4, 4 and 9 kcal per gram — and checked it against the stored value across the whole database. The two agree within the expected Atwater tolerance: no corrupted rows, no unit mix-ups.

These 7,694 rows are the only ones the AI is allowed to look up. Foods added by people are searchable and loggable, but they are deliberately kept out of the automatic lookup — see section 05.

The biggest silent error, handled explicitly.

Same food, more than double the difference — purely because cooking adds water. The pipeline treats it as a first-class field: the AI marks whether each amount is pre-cooking or cooked, and the database lookup respects that mark. "100 g of pasta" from a package weighs against the dry row; from your plate, against the cooked one.

An honest guess beats a wrong lookup.

Composite dishes — lasagna, a restaurant curry, your grandmother's stew — often have no single database row that honestly matches. Forcing a lookup there would swap one kind of wrong for a worse one. So when the match isn't confident, the line falls back to the AI's own estimate, and it is labeled as an estimate.

Every line carries a label saying where its number came from, and the meal carries the label its lines agree on:

The label is written by the server from what the row actually is. Nothing your browser sends can produce a USDA badge — the only way a line is labelled USDA is if a real FoodData Central row was read to price it, that row was found by a curated match rather than word overlap, and the portion is a USDA serving weight or a weight you gave. USDA numbers on a portion the model guessed wear the amber “est. portion” label instead: the number is USDA’s, the claim that it is this much is not.

Foods people add, without the usual consequences.

USDA does not have your local bakery's rye bread. When a search comes up empty you can add the food yourself, and it becomes searchable for everyone — the thing every big tracker does, and the thing that ruined most of their databases.

So the entry has to get past four checks first. Its calories are cross-checked against its own macros, and a figure that disagrees with 4·protein + 4·carbs + 9·fat is refused — in both directions, with a wider allowance downward for fibre, and an upward allowance only if you say the food contains alcohol, because alcohol is the one thing that carries energy the macros do not account for. It must state whether the numbers are for the food raw, dry or cooked. It must come with at least one serving and what that serving weighs. And a name that already exists is refused with a link to the entry it would have duplicated.

After that it is ranked, not trusted. A new entry is findable immediately and sits below the USDA rows until other people have actually used it. What counts is how many different people have logged it, never how many times — so nobody can promote their own entry by logging it fifty times, which is the hole this design exists to close. Anyone can report an entry, one report each, and reports are read by a person.

A packet with a barcode can be scanned instead of typed. The picture never leaves your phone — the code is decoded in the browser and only the digits are sent — and the digits are checked against their own check digit at both ends, so a misread that produces an impossible number is refused rather than answered with something that looks close. If the product is not in the database yet, that is the moment to add it: the packet is in your hand, which is the only time anyone can read its numbers accurately.

Recipes work the same way underneath and are the opposite in one respect: they are private. A recipe is priced from its ingredients and then behaves like any other food — searchable, portioned, loggable — but only for the person who wrote it. It also records what the finished dish weighs, separately from what went into it, because cooking moves weight in both directions: a stew loses water, a pot of rice gains it, and per-100 g figures taken from the raw sum are wrong for anyone who weighs a portion.

A community food never wears the USDA badge. It says COMMUNITY, everywhere, permanently. That is the whole bargain: a bigger database, and no confusion about which half you are looking at.