How the Diet Score Is Calculated: The Tatonia Method and Its Limits
Tatonia assigns a 0 to 100 diet fit score to every recipe. 10 profiles: balanced, high-protein, low-sugar, high-fiber, Mediterranean, keto-sensitive. How the score is built, which profiles are stable and which are still Beta, how USDA data is used. A guide that explains the method transparently.
The Tatonia Editors··10 min read
How well does a recipe fit a given user? The answer depends on the user. A recipe that suits a vegetarian may fall short for someone chasing high protein. A cake that looks healthy to a low-sugar reader may spike blood sugar fast.
Tatonia handles this question automatically: based on your chosen diet profile, every recipe receives a fit score from 0 to 100. A small chip on the recipe card, a detailed card on the detail page. A Beta tag sits next to it. This article walks through the method behind the score, why the Beta tag is there, and where you can trust it.
What the score is measuring
The diet score does not say whether a recipe is healthy. A "low-calorie" diet and a "high-protein" diet reward different things. The same recipe might score 92 on one and 35 on the other. The score answers "how well does this recipe match the diet you chose", it is not an absolute quality measure.
There are ten diet profiles at the moment: five are stable thanks to macro data, five run on USDA nutritional values and are still in Phase 2.
Five stable profiles (per-serving calorie/protein/carb/fat data is sufficient):
Balanced Eating: plates around 15 to 25 percent protein, 45 to 55 percent carbs, 25 to 35 percent fat
High Protein: at least 25g protein per serving
Low Calorie: under 350 calories, still filling
Vegetarian Balanced: no meat, plus good macro balance
Vegan Balanced: no animal products, plus adequate plant protein
Five profiles running on USDA data (per-serving sugar, fiber, sodium, saturated fat):
Low Sugar: recipes that do not spike blood sugar fast. Sugar comes from USDA FoodData Central values, with bonuses for protein balance and fiber.
High Fiber (Beta): at least 8g of fiber per serving. Whole grain, legume, vegetable heavy.
Low Sodium (Beta): under 600mg per serving. Heart-friendly, hypertension-aware. Close to the DASH dietary target.
Keto Sensitive (Beta): net carbs (total carb minus fiber) of 10g or less per serving, fat at 70 percent of calories or more.
Each profile uses different criteria with different weights. Totals always sum to 100.
How the calculation works
The score is produced by a rule-based engine. Not AI, deterministic math. The same recipe, with the same diet, always returns the same score.
Each diet has its own criteria list. For "High Protein", for example:
Protein amount (45 points): 25g or more per serving is full marks, less drops linearly
Protein density (25 points): lower kcal-per-gram-protein (≤12 kcal/g) is better
Satiety (20 points): hunger bar score in the 5 to 10 range is ideal
Sensible calorie range (10 points): 300 to 800 kcal
For "Vegetarian Balanced", the criteria shift:
Vegetarian match (35 points): full marks if the recipe has no meat, zero if it does
Adequate plant protein (25 points): 15g or more
Macro balance (25 points): all three macros within target range
Calorie range (15 points): 300 to 700 kcal
Each criterion uses a "smooth fit" curve. The closer you get to target, the higher the share; right at target you get full marks; above target you take a mild penalty. Instead of binary "pass / fail", the question is "how close". This approach is the one recommended by the WHO nutrient profiling literature.
The score splits into 5 bands:
85 to 100: excellent fit
70 to 84: good fit
50 to 69: moderate fit
30 to 49: weak fit
0 to 29: not a fit
A small coloured chip on the recipe card reflects the band: green for high, yellow for moderate, red for low.
Why the Beta tag is still there
Five profiles are stable, five carry the Beta tag. The difference is data coverage.
The five stable profiles (Balanced, High Protein, Low Calorie, Vegetarian Balanced, Vegan Balanced) need data we already have: per-serving calories, protein, carbs, fat. 100 percent of recipes carry these values, so the score is reliable.
The five USDA-driven profiles need deeper data: per-serving sugar, fiber, sodium, saturated fat. We compute these from ingredients rather than recipes. For every ingredient, we map it to its USDA FoodData Central entry, then scale by quantity to get the per-serving share.
Right now this mapping covers 86 percent of recipes. We mapped the top 80 most-used ingredients (olive oil, flour, onion, egg, chicken breast, lentils, and other staples) against USDA values. For recipes without a complete match, the score is flagged "approximate"; the "Diet Fit" card on the recipe detail page shows the data-match percentage.
The Low Sugar profile is slightly more robust because we use carbohydrate ratio as a fallback proxy when USDA data is missing, which is why we removed its Beta tag. The other four USDA profiles (High Fiber, Low Sodium, Mediterranean, Keto Sensitive) are still Beta because they have no proxy, so on recipes with low data coverage the score becomes shaky.
The next step in Phase 2 is mapping the top 100 to 200 ingredients; once coverage crosses 92 percent, those four labels drop the Beta status.
On the data side: 80 ingredients, 86 percent coverage
Tatonia's ingredient catalogue has 1387 distinct ingredient names. The top 80 by frequency are core staples: olive oil, water, butter, flour, onion, egg, salt, milk, garlic, yogurt, sugar, tomato, potato, rice. These 80 ingredients account for 85 percent of the RecipeIngredient table.
For each ingredient we store:
Per-100g calories, protein, carbs, fat
Per-100g sugar, fiber, sodium, saturated fat
Glycemic index when known
Unit conversion (1 egg = 50g, 1 cup = 200ml)
The aggregate calculation for a recipe runs as follows: ingredient list → NutritionData lookup for each → parse the amount string ("1 cup", "500 g", "half a teaspoon") to grams → multiply per-100g values × grams / 100 → sum → divide by serving count. The result is per-serving sugar, fiber, sodium, saturated fat.
Another factor is serving count. The 4-person version of a recipe and the 8-person version have the same calorie-per-protein ratio, but the absolute values change. We compute the score per serving, tied to the "Serves" value on the recipe page. If that value is wrong, the score drifts. In about 95 percent of recipes the serving count is correct, but we cannot bring the error rate to zero.
What the tag retrofit did
In our first release, looking at "Vegetarian Balanced" scores, we noticed that only 48 percent of vegetarian recipes actually carried the vegetarian tag, the rest had no meat but were not tagged. In that state the scores were lower than they should have been. The cause was simple: human hands, missing tags.
The fix was an automated check. We scanned every recipe's ingredient list, building a matcher for meat, poultry, fish, and shellfish patterns. When none of those hit, we added the vegetarian tag. The same matcher also checks for dairy, eggs, and honey, and adds the vegan tag when none are present. This pass added 1156 new tags.
The distribution after:
Vegetarian: 48 percent → 72 percent
Vegan: 22 percent → 31 percent
The auto-tagging is not 100 percent accurate. Edge cases like "broth" create ambiguity, and manual review will follow. For now we lean conservative: when in doubt, we do not tag. So there are still untagged vegetarian recipes out there, but nearly every tagged recipe genuinely is vegetarian.
Where the score is reliable
The ten profiles fall into two reliability tiers.
Stable (existing data is sufficient, no Beta tag):
Balanced Eating
High Protein
Low Calorie
Vegetarian Balanced
Vegan Balanced (the B12 signal is missing, a future version will add an explicit warning)
Low Sugar (USDA plus carb fallback, 86 percent coverage)
USDA-dependent, still Beta:
High Fiber
Low Sodium
Mediterranean
Keto Sensitive
The Beta profiles work on about 86 percent of recipes; on low-match recipes, the "Diet Fit" card displays a "X percent match, limited data" notice. To promote them, we need to push ingredient coverage past 92 percent, which the next USDA seed wave (from top 80 to top 130) will achieve.
The reason for this graded approach is to avoid presenting a wrong result as if it were right. When a user picks "Low Sodium", showing a fabricated score on a recipe without sodium matching is worse than honestly saying "30 percent match, limited data".
Limits and proper use
The score is a recommendation system, not medical advice. A diabetic user should not substitute it for the Glycemic Index table or for their dietitian. Our "Low Sugar" score considers total per-serving carbohydrates and cannot fully distinguish between fast-digesting refined sugar and slow-digesting whole grains. Phase 2 will add a glycemic-index layer to close this gap.
Other limits:
No personalised calorie calculation. "Low Calorie" uses a 350 kcal threshold; depending on your age, weight, and activity, the "low" threshold for you may be different.
Allergens like gluten, lactose, or nuts do not enter the diet score. They run as a separate filter on the recipes page, "exclude allergen".
No micronutrient (vitamin, mineral) calculation. Iron, B12, calcium, and similar values will enrich the score in Phase 3.
The general rule is to treat the score as a hint. A recipe scoring 90 says "this may suit your diet", not "eat this". A recipe at 30 says "this does not suit your diet", not "do not eat this". Looking at the direction of the score rather than just the number is the better habit.
Getting the most out of the score
A user with the score active sees it in three places: a small chip on the recipe card, a detailed card on the detail page, a sort option on listing pages.
On the recipe card: only the score and its band colour are visible, for quick browsing. If a green tile catches your eye, that is the signal to open and look closer.
On the detail page: a 0 to 100 progress bar plus a sub-score for each criterion. You can see exactly why the score is what it is, which criterion is short. "Got 35/35 for being vegetarian, but protein is 8g while the target is 15g, so only 13/25 instead of the full 25" is how it reads.
On listing pages: visit /tarifler and a sort option called "Fits my diet" appears (only when you have selected a diet). Click it and every recipe is ranked by your profile, highest to lowest. Filter selections (category, cuisine, allergen) work in combination.
When you head to the Smart Assistant with an ingredient list, the same data engine runs in the background. A small chip on each suggestion tells you "how well this suggestion fits your diet" from a single glance.
Transparency and feedback
The scoring algorithm is open. Thresholds, weights, and calculation logic live in the source code and will soon be public on GitHub. If a recipe's score feels too low or too high, the settings page has a "Change my diet" link, you can temporarily switch profile and compare.
A feedback widget is on the way: a one-tap "Does this score match your view?" check. The answers will help us calibrate Phase 2 thresholds and beyond.
The practical takeaway of the current Beta status: use the score, but do not let it decide alone. Look at the ingredient list, the calorie value, and the balance of your own plate too.