Data & methodology

Food composition data

All food/nutrient data comes from USDA FoodData Central (FDC) CSV exports: Foundation Foods, SR Legacy, and Branded Foods. Nutrient amounts are USDA's own analytical or labelled values — not re-derived or adjusted.

• Foundation Foods / SR Legacy — whole/minimally-processed foods with USDA lab-analysed nutrient profiles. These are what amino acid and micronutrient data mostly comes from.
• Branded Foods — packaged/retail products, sourced from nutrition-facts-panel data submitted to USDA. This is what barcode scanning resolves against (the gtin_upc field). Branded foods essentially never have published amino acid data, so they can't be scored for DIAAS/PDCAAS — that's a real gap in the underlying data, not a bug.

USDA nutrient numbers (fdc_nutrient_nbr) are verified directly against each dataset's own nutrient.csv rather than assumed stable — they aren't always: for example arachidonic acid's nutrient number differs between Foundation Foods and SR Legacy, and fibre is reported under two different lab methods depending on the food. Both are mapped explicitly rather than picking one and hoping.

Provenance & confidence

Every displayed value traces through the same chain: Food → FDC ID / dataset → USDA nutrient number → the FoodNutrient row → any recipe/diary aggregation → the DRV comparison. A food's own /provenance API endpoint exposes this chain directly (dataset, nutrient numbers, digestibility sources) for anyone who wants to check a number rather than trust it.

Raw nutrient amounts are always exactly what USDA reported — this app never estimates or imputes a micronutrient amount; a food either has the row FDC gave it, or has no row for that nutrient at all. What actually varies in confidence is everything built from those amounts:

• Digestibility (DIAAS/PDCAAS) — measured or estimated, as described above. For a recipe or a diary day, this is computed as the weakest link across every ingredient that contributed protein: the combined result is only measured if every contributing food's digestibility was; one estimated ingredient makes the whole combination estimated. This used to just be left blank for recipes ("a blend, not a single tag") — it's now computed for real.
• Iron haem/non-haem split — same measured/estimated tagging, described in the bioavailability section below.
• Daily reference values — tagged live_confirmed (this specific figure, or an increment on it, was independently checked against a live/primary source this session — currently vitamin A, retinol, calcium, and iron) or secondary_source (the default: sourced from the named RNI/PRI/RDA table via a secondary comparison table, consistently reproduced but not independently re-verified against the primary document page-by-page). Energy targets get their own tag, personalized_calculation, since they're computed live from your own profile rather than looked up from a population table at all.

These are deliberately coarse, hand-set tiers describing real, checkable facts about how each value was sourced — not a fabricated numeric confidence score. A single number implying false precision would be worse than no number at all.

Live vs Snapshot Mode

Every score and DRV comparison the API returns is stamped with a methodology_version (both a DRV-matrix version and a scoring version — see the badge on the diary page). By default, Live Mode is the only mode: every diary day is recomputed from current code and current data every time you look at it. If this app's methodology changes later — a corrected DRV figure, a new digestibility source, a scoring fix — a day you logged last month will reflect that change the next time you view it, not the methodology that was in effect when you logged it.

Snapshot Mode is the opt-in alternative: from the diary page, you can explicitly freeze a day's full computed result, including the methodology versions in effect at that moment. A snapshot is immutable — taking one a second time is refused, and logging more food for that day afterward doesn't change it. This is what makes the methodology-version stamping actually auditable: without ever taking a snapshot, "methodology_version" is just a label on numbers that keep moving; with one, you have a fixed point to compare today's live numbers against.

Snapshots are never taken automatically. A day you never explicitly snapshot only ever exists in Live Mode — this app doesn't claim to retroactively reconstruct the methodology that was in effect on a day before this feature existed, and won't pretend to.

Protein quality (DIAAS / PDCAAS)

DIAAS (Digestible Indispensable Amino Acid Score) and PDCAAS (Protein Digestibility-Corrected Amino Acid Score) both compare a food's indispensable amino acid profile against a reference pattern, then correct for how digestible that protein actually is. The reference patterns (mg amino acid per g protein) are from FAO. 2013. Dietary protein quality evaluation in human nutrition, Table 4.1 — the current FAO/WHO standard.

DIAAS uses per-amino-acid true ileal digestibility and is not capped at 100%. PDCAAS uses a single overall digestibility coefficient (typically faecal) and is capped at 100%, per standard convention.

Digestibility coefficients — two tiers, always labelled

Every score is tagged measured or estimated so you always know which you're looking at:

• Measured — a real published digestibility study for that specific food. Deliberately a short list: egg and cooked chicken meat come from Kashyap et al. 2018 (Am J Clin Nutr 108(5):980-987, human ileal, dual stable isotope). A handful of PDCAAS values (rice, corn, oats, peanuts, soybeans, beans, lentils/chickpeas) come from the classic FAO (1991) Protein Quality Evaluation true-digestibility table, as widely reproduced in nutrition literature — rice was additionally cross-checked against an FAO document citing WHO 1985/Hopkins 1981 human data.
• Estimated — a broad food-category coefficient (e.g. "meat" ≈ 0.90, "legumes" ≈ 0.80) applied when no food-specific measurement exists. This is a coarse approximation, not a citable number for that food — it exists so most ingested foods get some usable score rather than none.

Missing amino acid or digestibility data isn't silently treated as zero — a food or recipe with an incomplete profile is reported as unscorable rather than given a number that understates it.

Vitamins, minerals, fibre & fats — daily reference values

Each nutrient has up to four target values — adult male, adult female, pregnant, lactating — so gap analysis reflects your actual profile rather than one generic figure. Sourced in this priority order:

1. UK Reference Nutrient Intake (RNI), where one exists
2. EFSA Population Reference Intake / Adequate Intake, next
3. US RDA/AI, as a last resort

Confidence varies per nutrient and is tracked individually — hover any nutrient in the app for its specific source and confidence note (e.g. "UK RNI; pregnancy increment confirmed live" vs. "US RDA/AI — no UK or EFSA figure set, no confirmed sex split"). Where no pregnancy/lactation increment could be confidently found, that value explicitly falls back to the adult-female figure rather than an invented estimate.

The public, signed-out food lookup always shows the adult-female baseline (no profile to personalize against). Diary, recipe, and trends views use your actual profile once signed in.

Bioavailability estimate (iron, calcium:phosphorus)

The diary's per-meal iron absorption estimate and day-level calcium:phosphorus ratio are the most heavily caveated numbers in the app — nutrient bioavailability is genuinely complicated, and this uses a deliberately simplified model built from real published constants rather than a full research-grade algorithm.

Iron

• Haem iron is fixed at 25% absorption, and 40% of a meat/fish/poultry food's total iron is treated as haem — both constants from the Monsen algorithm (Monsen ER et al. 1978, Am J Clin Nutr 31:134-141; adapted as Monsen & Balintfy 1982). Recent work suggests the 40% figure itself varies by food source; used here anyway as the most widely-cited single value.
• Non-haem iron absorption uses a two-tier model: 5% baseline, or 10% "enhanced" if the meal has ≥25mg vitamin C (FAO's Human Vitamin and Mineral Requirements, 2004, Ch.13, recommends this as a per-meal target) or contains any meat/fish/poultry. This is an explicit simplification of Monsen's real bracketed model — the exact published bracket table couldn't be sourced — not a transcription of it.
• Real per-food haem/non-haem splits (when FDC reports them) are used when present and marked measured; otherwise the 40% category split is used and marked estimated. In practice, essentially every food in this app's data today goes through the estimated path — FDC's heme/non-heme iron fields exist but aren't populated in the ingested datasets.
• Phytate is now shown separately (see "Phytate" below), from a different source than FDC — but is not yet incorporated into this absorption estimate. Tannins and polyphenols remain completely untracked.

Calcium:phosphorus

ESPGHAN (European Society for Paediatric Gastroenterology Hepatology and Nutrition) recommends a 1:1–2:1 calcium:phosphorus ratio by weight. More recent research (NHANES 2005-2006 cross-sectional data) found no association between this ratio and bone mineral density in older adults — the app presents the ratio as informational context, not a strict target, and says so in the guidance text itself.

Phytate

Shown on a food's own page (free for every account, on identical terms — nothing about this feature is a paid/Professional/Enterprise benefit), sourced from FAO/INFOODS/IZiNCG's PhyFoodComp, version 1.0 — a food-composition compilation for phytate, entirely separate from USDA FoodData Central. Commercial-use permission from FAO is still pending as of this writing; while that's unresolved, phytate data is restricted to this ordinary personal view and internal research use only — never a public API, Professional/ clinician output, Enterprise/batch feature, or paid export.

Phytate (phytic acid) can reduce how much iron, zinc, and calcium a meal's other foods contribute to absorption — but it's also present in many nutritious whole grains, legumes, nuts, and seeds, and isn't simply something to avoid. This page does not compute a phytate:zinc or phytate:iron ratio, and does not feed into the absorbed-iron estimate above — that's a deliberately separate, not-yet-built piece of work.

• Every value is labelled estimate — PhyFoodComp entries are matched to this app's food catalog by category/analogue, not confirmed as the exact same product, cultivar, or preparation as the source study measured.
• Different phytate fractions (phytic acid by various analytical methods, phytate-phosphorus, individual vs. summed inositol phosphates) are not interchangeable — this app never averages across methods and never sums an individual fraction with a summed total that already includes it. Where more than one incompatible measurement exists for a food, all of them are shown rather than collapsed into one number.
• A food's preparation state (raw, boiled, etc.), where the source recorded one, is shown alongside its value — a mismatch between what you're asking about and what was actually measured is flagged, not hidden. This is informational only, not a filter: a flagged observation is still shown, never silently excluded, since suppressing it would claim a precision the underlying match doesn't actually have.
• Missing or below-detection-limit source data is shown as missing, never silently treated as zero.

Energy (calorie) target

Personalized daily energy targets use the Mifflin-St Jeor equation (the modern standard, more accurate than the older Harris-Benedict formula) times a standard activity-level multiplier:

men:   BMR = 10×weight_kg + 6.25×height_cm − 5×age + 5
women: BMR = 10×weight_kg + 6.25×height_cm − 5×age − 161

Pregnancy adds a flat +200 kcal/day (commonly-cited UK SACN figure, applied flat rather than trimester-aware for simplicity); lactation adds +500 kcal/day (first 6 months). This requires weight, height, birth year, sex, and activity level all set in your profile — without all five, no target is shown rather than a guessed one.

Weight-loss calorie target

If your profile goal is set to "Lose weight" or "Reduce visceral fat", recipe and diary calorie targets switch from plain maintenance EER (above) to a deficit target — shown with a visible note wherever it appears, never applied silently.

• Deficit size: 15% below EER for adults, reduced to 10% for adults 65+. Older adults restricting calories are at greater risk of losing lean mass alongside fat — a concern well documented in geriatric nutrition literature (e.g. Villareal et al. 2011, New England Journal of Medicine, on combined diet-and-exercise weight-loss interventions in older adults) — so a smaller, more conservative deficit is used.
• Where 15% comes from: not a single official number from one governing body — it sits inside the commonly-reproduced "moderate, sustainable" ~10-20% range used across mainstream sports-nutrition/dietetics guidance for general (non-athlete, non-clinical) fat loss. More conservative than 20-25%+ (typically recommended only under direct supervision), and often smaller than the popular "500kcal/day" rule of thumb, which is itself a larger percentage for anyone below-average maintenance calories, since it's a flat number rather than a %. Treat 15%/10% as a reasonable, safety-conscious default, not a clinical prescription — nothing in this app can know if a larger or smaller deficit is actually right for you.
• Safety floor: the target never goes below 1,200 kcal/day (women) or 1,500 kcal/day (men) — minimums commonly reproduced in NIH/NHLBI-style guidance and widely echoed by registered-dietitian sources as the point below which unsupervised dieting risks micronutrient inadequacy. Whichever number — the % deficit or the floor — is higher wins, so the floor only ever raises the target back up, never lowers it further.
• Pregnancy/lactation: never deficit-adjusted, regardless of goal — active calorie restriction during pregnancy or lactation isn't generally considered safe without direct clinical supervision, so these profiles always see plain EER (which already includes the flat pregnancy/lactation increments above).
• "Reduce visceral fat" uses the exact same calculation as "Lose weight". Visceral fat responds to the same overall energy-deficit mechanism as fat anywhere else in the body — there's no established way to calorie-target one fat depot over another, and inventing a different number for it would be exactly the fabricated precision this app avoids everywhere else.

This is a default, not a recommendation tailored to you — if you have a specific medical reason to eat more or less than this, or a condition where calorie restriction isn't appropriate, talk to a doctor or registered dietitian rather than relying on this figure.

Goals and nutrient-priority weighting

A profile can hold several goals at once, ranked by priority (the order you picked them in the profile page). Where a goal actually changes something, each active goal contributes independently, combined as a priority-weighted sum: your first-picked goal gets full weight, your second gets half, your third a third, and so on. A lower-ranked goal still nudges things, it just doesn't dominate over one you picked first.

Longevity, athletic stamina/endurance, athletic strength, and athletic power each give extra weight to a specific set of nutrients when gap-suggestions or meal-optimize pick which nutrient to target — a modest boost (30%), deliberately small enough that a genuinely severe gap in an unrelated nutrient still wins. Framed as "aligned with research on X", never a promise about an individual outcome this app has no way to verify:

• Longevity: protein, fibre, ALA (omega-3), magnesium, potassium — nutrients repeatedly associated with healthy-aging and cardiometabolic outcomes in epidemiological literature (e.g. higher protein intake for sarcopenia prevention in older adults; omega-3 intake and cardiovascular mortality). ALA specifically, not EPA/DHA — EFSA/WHO only publish a combined EPA+DHA target, not an individual DRV either fatty acid can be measured against, so only ALA can actually be ranked as a gap here.
• Athletic stamina/endurance: iron and potassium — endurance training's well-documented depletion risks (foot-strike haemolysis, sweat electrolyte loss). Sodium isn't included despite the same sweat-loss reasoning applying to it: this app tracks sodium as a maximum-guideline figure with no upward target, so it has no "gap" to ever prioritize.
• Athletic strength: protein, calcium, magnesium, zinc — muscle protein synthesis, bone loading, and muscle-contraction function.
• Athletic power: protein, phosphorus, zinc — phosphorus specifically for the fast ATP/phosphocreatine energy system explosive, short-duration effort draws on, distinct from strength training's more sustained contractions.

Reduce carbon footprint and blood-sugar stability both give ingredient/recipe suggestions a modest nudge toward lower-tier candidates, using the same priority-weighted-by-rank policy as the nutrient-emphasis goals above. Neither is a precise per-food measurement — USDA FoodData Central (this app's only data source) doesn't publish per-food greenhouse-gas/land-use figures or glycaemic-index values, and no supplementary dataset is joined against the catalogue. Both instead use coarse, name-keyword category tiering anchored to published research (food-system life-cycle-assessment literature for carbon; the Foster-Powell/University of Sydney glycaemic-index tables for blood sugar) — honestly low-confidence, never a fabricated precise figure, and never a per-product measurement of the specific food in front of you: a "very high" carbon tier is not a lifecycle assessment of that product, and a "low" glycaemic tier is not a lab-measured glycaemic index for it.

A recipe or recipe-pair has no single tier of its own — the classification comes from whichever ingredient dominates the recipe by weight, which can miss what actually matters (a small amount of a very-high-carbon or high-GI ingredient elsewhere in the recipe isn't reflected). Every suggestion's own "Why this ranked here" panel states which food the classification actually came from, so this is never hidden inside a single unexplained number.

Blood-sugar stability is the more conservative of the two, for a few reasons worth stating plainly:

• Glycaemic index (GI) and glycaemic load are not the same thing — GI alone doesn't account for portion size or how much carbohydrate a serving actually contains, both of which materially change the real blood-sugar effect of eating something. This app tiers GI category only, not glycaemic load.
• Real GI varies with preparation, variety and ripeness enough to cross an entire tier boundary for some foods — common staples (bread, rice, potato, banana) are deliberately left untiered altogether rather than guessed, because their name alone can't reliably convey which side of that boundary a given serving falls on.
• Meat, fish, eggs, cheese and nuts are tiered "low" on a different basis than a real researched low-GI food (lentils, most fruit and vegetables): GI is only defined for carbohydrate-containing foods at all, so a negligible-carbohydrate food isn't "tested low" — the concept doesn't meaningfully apply to it. Every suggestion's own breakdown says which of the two applies.
• This is general nutritional information, not a prediction of your own blood-sugar response and not medical advice — individual glucose response depends on far more than any single food's category.

Not implemented, for a different reason than a missing dataset: a broader recovery/anti-inflammatory goal beyond the omega-3 signal already covered under longevity. USDA published an antioxidant-capacity (ORAC) database and then withdrew it in 2012, citing no evidence that a food's lab-measured antioxidant capacity translates into a real antioxidant or anti-inflammatory effect in the body — so even where polyphenol/antioxidant composition data exists elsewhere, wiring it in as an "anti-inflammatory" signal would be overstating what the science actually supports.

Sodium:potassium ratio, leucine threshold, protein distribution, absorbed protein

Four more diary checks, each computed from data already tracked rather than anything new:

• Sodium:potassium ratio — WHO recommends less than 2000mg sodium and at least 3510mg potassium per day, implying a target ratio around 0.57. Both nutrients are directly tracked from FDC, so this is a real ratio against a real published target — presented as context, not a pass/fail grade.
• Leucine threshold — the minimum leucine in a single meal to maximally stimulate muscle protein synthesis, from Norton & Layman (2006) and widely reproduced since: ~2.5g for younger adults, ~3g for older adults (age 65+, reflecting anabolic resistance). Computed from each meal's actual logged foods' leucine content; defaults to the lower, younger-adult threshold if your profile has no birth year set.
• Protein distribution — the same leucine-threshold check applied to every meal of the day, so you can see whether protein is spread out enough to clear the threshold more than once, rather than concentrated into a single meal (research, e.g. Mamerow et al. 2014, associates even distribution with better muscle protein synthesis than the same daily total skewed into one meal).
• Total absorbed protein — the day's total protein weighted by DIAAS/PDCAAS digestibility, i.e. how much actually gets absorbed rather than the raw "protein on the label" figure. DIAAS uses the digestibility of whichever amino acid is limiting that day's mix (the one that governs protein synthesis capacity); PDCAAS already reduces to one overall coefficient. Either is left blank if that method's digestibility data is incomplete for the day's foods — never guessed. Compared against a personalized daily target: body weight × an activity-level figure (0.8g/kg sedentary up to 1.6g/kg very active — commonly reproduced sports-nutrition ranges, not one official table), with a 1.0g/kg floor for healthy adults 65+ (PROT-AGE Study Group, Bauer et al. 2013 — countering age-related anabolic resistance) and a flat +6g/+11g increment for pregnancy/lactation (UK COMA/SACN). Needs weight, birth year, and activity level set in your profile; otherwise shown without a %.

Not implemented: oxalates and tannins — USDA FoodData Central doesn't track either as a nutrient, so there's nothing to compute from. Phytate is tracked from a separate source (see the Phytate section above) but isn't part of this protein-requirement calculation — see "What this app doesn't do" below.

Grocery budget estimate

Prices are entirely user-entered — this app doesn't call any grocery-pricing API or database. You tell it what a package actually costs (price + package size) for a food you buy; the weekly shopping list multiplies that out against what your meal plan needs. Foods with no price set are shown as missing, not defaulted to zero or estimated from anywhere else.

What this app doesn't do

• No tannin, oxalate, or polyphenol data — real inhibitors of mineral absorption that FDC simply doesn't track. Phytate data exists (see the Phytate section above), from a separate source, but isn't wired into the absorption estimate or any molar-ratio calculation yet. (This is also why there's no broader antioxidant/anti-inflammatory goal — see the Goals section above for why that's a science gap, not just a data one.)
• No real glycaemic-index/load data — a type 2 diabetes condition is stored for reference (see Profile). The "blood-sugar stability" goal uses a coarse, name-based tier estimate instead (see the Goals section above), not a measured figure; FDC doesn't publish real GI values for the large majority of foods.
• No real per-food carbon-footprint/emissions data — the "reduce carbon footprint" goal uses a coarse, name-based tier estimate instead (see the Goals section above), not a measured figure.
• Branded/packaged foods can't be scored for protein quality — nutrition labels don't publish amino acid profiles.
• "Estimated" digestibility and iron-split values are broad category averages, not measurements of the specific food in front of you.
• DRV confidence varies a lot by nutrient — some increments are confirmed against a live source, others are commonly-cited figures recalled from secondary sources. Hover any nutrient for its specific note.
• This is a personal nutrition-tracking tool, not medical advice — bioavailability and DRV figures are population-level estimates, not individualized clinical guidance.