Alkemos Food Database — Methodology and Sources

The Alkemos food database is a nutrition reference of 8,830 foods. Every entry carries the same four facts — calories, protein, carbohydrate, and fat — standardized per 100 grams, plus fiber and sugar where the source provides them, a food category (9 top-level families), and a default serving expressed in real grams.

The database is bilingual by design: each row holds an English name and an Arabic name, with Arabic default-serving descriptions on the hand-curated core. It powers the macro workflow end to end — the meal planner's live per-meal and per-day totals are computed from these same rows, so the numbers you plan with and the numbers you look up are one and the same source.

The structure splits into two layers with different curation depths: a hand-curated core of 80 foods (written bilingual names, gram-anchored default servings, and nutrition-goal tags such as high-protein or keto-friendly), and a reference long tail of 8,750 rows carrying standardized English nutrition values. Both layers follow the per-100g convention; the counts on this page are computed live from the shipped data, not copied from a document.

The curated core was written by hand: bilingual names, default servings measured in grams, and the tag facets that drive the nutrition-goal collections (high-protein, low-carb, keto-friendly, and their siblings). Its values follow common kitchen-state references and are the rows the sitemap advertises in both languages.

The long tail derives from the U.S. Department of Agriculture's public nutrition reference data (USDA) — the standard open reference for per-100g food composition. Long-tail rows ship English text as their Arabic name field; rather than machine-faking Arabic labels, the Arabic mirrors of untranslated rows are excluded from indexing (noindex, follow) so crawl budget and Arabic searchers never land on semantically-broken pages. The English originals remain fully indexable.

This is the documented crawl-budget policy, not an oversight: the sitemap advertises the 80 curated foods in both languages (80 × 2 URLs), while the long tail stays reachable through the foods explorer's pagination and related-food links and earns indexing on merit.

Every value in the database is expressed per 100 grams of the food in its documented state — the international standard for food composition tables, and the convention that makes portions pure arithmetic: a 37g tablespoon of a food is 0.37 × the per-100g values, whatever your scale reads. State is the variable to watch, not math: raw and cooked weights of the same food differ (water loss concentrates cooked values per gram), so match the weighing state to the entry and the arithmetic stays honest.

Default servings are anchors, not guesses: each carries a gram equivalent (for example, one medium chicken breast ≈ 150g) so a quick estimate lands near reality instead of inside a 120–250g household range. The meal planner accepts any gram figure and recomputes live — the same per-100g rows feed both surfaces.

2,489 foods carry hand-written Modern Standard Arabic names and, on the curated core, Arabic default-serving descriptions — written by editors, not machine-translated, so the Arabic surface reads as Arabic (the editorial law bans dialect and Latin mixing on these surfaces). The remaining 8,750-row long tail keeps its English name in the Arabic field by design, and those untranslated mirrors are excluded from indexing rather than faked.

The Arabic layer is what makes the reference usable for the Arabic-speaking fitness audience — most of whom meet macro numbers for the first time in Arabic search results — and it is why the Arabic food pages, collections, and this methodology page carry reciprocal language pairings (hreflang) with their English originals.

The database is frozen reference data with batch updates: values change in deliberate, versioned batches — never silently per-request — and each food page is served from a long-lived cache (a 7-day revalidation window) so a cited number stays the number a returning reader saw. The per-page nutrition facts, the methodology counts, and the meal-planner arithmetic all read the same shipped data snapshot.

When a batch lands (new curated foods, expanded Arabic coverage, or corrected values), the change rides a repository commit with its documentation — which is precisely the audit trail a cited reference should be able to show.

The values are reference averages, not your exact food. Between varieties, brands, cuts, ripeness, and cooking method, a real chicken breast or a real banana drifts around the database figure — reference tables are built to average that drift, not eliminate it. Per-100g values describe a documented state; converting between raw and cooked weights is the citing writer's responsibility (the macro-accuracy guide covers the conversion rules).

The long tail carries standardized English reference values, so it does not include your local brand's specific US nutrition label; for packaged goods, the label wins (regulators allow it a tolerance margin the database cannot know). And nutrition is an evolving science: a frozen reference is honest about its snapshot date — cite with an accessed date, which the format below includes.

Coaches, writers, and students may cite the per-100g values with the formats in the block below — cite the specific food page (or the database page), include an accessed date, and link the page you cite. The Arabic-language format is included for Arabic writing.

Content and data are offered under the site's terms (see the terms page); the citation format itself is free to use. What we ask in exchange for a citation: keep the accessed date — a citation without a date silently turns a reference snapshot into an unbounded claim.