The number I stopped trusting
The moment that decided this was small. I scanned a package, watched a full nutrition panel appear in under a second, and caught myself accepting it without reading it. Then I looked up the same food in the second source and got a different set of numbers. Neither was obviously wrong. Both were plausible. I had no way, standing in my kitchen, to say which one belonged in my catalog.
That is the whole problem in one sentence: an import is fast enough to feel authoritative, and speed is not accuracy. So in Pantensa an imported product arrives as a draft — filled in, ready, and waiting for you to confirm it — rather than as a finished entry that silently joins your data.
This post is the reasoning, because the behaviour looks like friction until you know what it is protecting.
Where the numbers come from
Pantensa reads two public sources. Open Food Facts is a collaborative database of packaged food, built by people photographing and transcribing labels; it is where a barcode scan usually lands. USDA FoodData Central is the US Department of Agriculture’s database of foods, which includes analytical data for generic ingredients — the flour, the chicken thigh, the dry lentils — alongside a large branded set.
Both are good. I chose them over a commercial nutrition API deliberately: they are open, they cite their provenance, and neither of them can decide one morning to price me out of my own users’ data. But “good” is not “identical”, and the places where they differ are not random.
Three ways an imported number goes wrong
The sources disagree with each other
USDA FoodData Central is not one dataset. It carries several — laboratory analyses, legacy reference values, survey data, and manufacturer-submitted branded records — and the same food can appear in more than one of them with different values. That is not a defect. A lab measurement of a specific sample and a manufacturer’s declaration for a product line are answering different questions. But when a product page has to display one number, something has to pick, and I would rather that something be a person who knows which question they are asking.
Open Food Facts adds a second kind of disagreement. It is crowd-sourced, which is its strength — it tracks real packages in real markets, including ones no American database has ever heard of — and also means a record can be incomplete, or entered into the wrong field. The most common failure I ran into was values for one serving typed into the per-100-g fields. A human spots that instantly because the numbers are too large for the food. Software has to be told.
The package changes and the record does not
Recipes get reformulated. Sugar comes down, oil goes up, a bar gets two grams lighter and keeps its barcode. The database entry reflects whatever the package said when someone last transcribed it, and there is no signal that pushes an update into your catalog when a manufacturer changes the recipe.
The one authority on what you are actually eating is the package in your hand. The review step puts you in front of the imported values while you are still holding it — the only moment the comparison is free.
Serving sizes do not convert cleanly
This one is the quietest and it bites the hardest. European labels declare nutrition per 100 g. US labels declare it per serving, with the serving defined by the manufacturer. Converting between them requires the serving weight in grams, which is sometimes absent, sometimes rounded, and sometimes given in a household measure — a cup, a slice, a biscuit — with no gram figure at all.
On top of that, label rounding is a legal procedure, not a mistake. The US rules set the increments explicitly, and they are coarser than most people assume:
| On a US label | Rounded to | Can read zero below |
|---|---|---|
| Calories | nearest 5 up to 50 kcal, nearest 10 above 50 | 5 kcal (may) |
| Total fat | nearest 0.5 g below 5 g, nearest 1 g above 5 g | 0.5 g (must) |
| Sodium | nearest 5 mg from 5–140 mg, nearest 10 mg above 140 | 5 mg (must) |
Increments from 21 CFR 101.9(c)(1), (c)(2) and (c)(4), current as of 13 August 2026.
Read the last column again, because that is the one that compounds. A tablespoon of oil at 0.4 g of fat is legally 0 g, and a snack at 4 kcal is legally 0 calories. Both declarations are correct. Neither is zero. Those rules are perfectly sensible on a package, where the question is roughly what am I eating. Multiplied by four servings and repeated across a week of meals, they drift.
So a per-serving import is not a smaller version of a per-100-g import. It is a different measurement with rounding baked in, and telling the two apart is exactly the kind of judgement a confirmation step is for.
What “draft” means in practice
Concretely: a scan or a database search fills the product’s fields, you see them before anything is saved, you fix what is wrong, and then it enters your catalog. That is the whole ceremony. It takes seconds, and it happens once per product.
The economics are lopsided in a way that made this easy to decide. Your catalog is built once and reused constantly — a product feeds recipes, recipes feed planned meals, planned meals feed your daily totals and your history. A ten-second check at import time is paid once. A wrong number is paid every single time that product appears, forever, and it is nearly invisible after the fact, because nothing in a total looks wrong. You would have to already suspect the entry to go find it.
That asymmetry is why I am comfortable spending your attention here and almost nowhere else in the flow.
What I am not doing
I am not going to auto-select the “most confident” value and hide the choice. In an interface, a silently chosen number and a verified number look exactly the same, and that is the confusion I am trying to avoid — not create.
I am not going to claim full coverage. Barcode lookup works well for widely distributed packaged goods and unevenly for local, store-brand and regional products. When nothing comes back, you enter the product yourself, and after confirmation it is indistinguishable from an imported one.
And I am not going to present any of this as clinical accuracy. These are the numbers on your food, transcribed and checked by you. That is a genuinely useful thing to track. It is not a laboratory, and I would rather say so on a blog than imply otherwise in a product.
Where this goes
Pantensa’s first release is nutrition-first: products with nutrition data, camera barcode scanning, database search, recipes, meal planning, tracking and history. Pantry mode — stock, expiry dates, shopping lists built from a plan — is coming next, and is not in the first release. But it is the reason the confirmation step matters more than it might appear. Everything later is built on the same product entries you are confirming now. Data you approved once keeps paying off; data you never looked at compounds in the wrong direction.
A draft you confirm is not the product being unsure of itself. It is the product being honest about which parts it knows and which parts only you can.