How we check the numbers
Where our figures come from, what we do with them, and the sums behind every comparison on this site. If you want to check our working, this is the page for it.
1. We never make a number up
No AI and no rule of thumb is ever allowed to invent a nutritional value on KnowDish. If a brand doesn’t publish the fibre, the saturated fat or the salt, we store nothing at all — NULL in the database — and the page tells you it isn’t published.
We never turn a missing value into 0g. A meal that simply didn’t declare its fibre would then look identical to one with genuinely none, and every comparison built on it would be wrong.
2. The sums we use
Protein Density (Grams of Protein per 100 kcal)
Measures how much protein you get for every 100 calories of food consumed. Useful for individuals looking for maximum protein efficiency without surplus caloric load.
Protein Energy Percentage (% of Total Calories)
Using the standard Atwater factor of 4 calories per gram of protein, this calculates what percentage of the meal’s total caloric energy comes from protein.
Weight-Normalised Calories and Protein (per 100g)
Calculated strictly when a verified total serving weight in grams is published by the provider. If serving weight is unknown, this metric evaluates to missing_input.
Price per 25g Benchmark Protein
Determines the cost to acquire a standard 25-gram serving of dietary protein from this meal, based on current non-promotional pricing.
3. Why we don’t score meals out of 100
Products often create artificial numbers like “KnowDish Health Score: 87/100”. We intentionally reject this pattern because nutritional value is context-dependent:
- An endurance athlete needs higher carbohydrates;
- A bodybuilder prioritises protein density and protein calorie percentage;
- Someone managing hypertension requires lower sodium and saturated fat;
- Someone with coeliac disease requires strict gluten exclusion.
KnowDish exposes transparent, measurable dimensions so you can make informed decisions aligned with your individual goals.
4. Putting different portion sizes on the same footing
Providers express nutrition per serving, per 100g, or per container. We tag every meal with its native serving_basis. When comparing meals with differing portion weights, our comparison engine displays both the per-serving values and the weight-normalised per-100g values side-by-side.
5. Cooked meals and recipe kits are not the same purchase
KnowDish indexes two formats, and classifies them at the product level rather than the brand level.
Prepared Meal
Arrives fully cooked; the customer reheats it. Published nutrition describes the food as delivered, and the price buys that cooked food.
Meal Kit
Arrives as pre-portioned raw ingredients plus a recipe; the customer cooks it. Published nutrition describes the recipe cooked to instruction and assumes store-cupboard items the box does not ship, so it is not strictly “as delivered”. The price buys ingredients, not a finished meal.
Why classification is per product, not per brand. Several UK operators sell both formats under one name. Gousto sells recipe kits alongside a Heat & Eat prepared range; Mindful Chef sells recipe boxes alongside frozen ready meals. Labelling a whole brand as one format would mislabel part of its catalogue, so product_type lives on the meal record. The provider record notes what a brand sells overall, but it is only a browsing aid.
What this changes in a comparison. Nutrition rows stay readable across formats, subject to the store-cupboard caveat above. Price rows do not: £4.25 per serving of a recipe kit and £7.85 for a cooked meal are not the same purchase. When a comparison set mixes formats, the engine emits a MIXED_PRODUCT_TYPE notice and marks every price row as descriptive rather than a ranking. It does not hide the numbers, and it does not adjust them to force agreement — it states which rows cannot be read as a league table.
6. Where a number came from, and when we checked it
Every record carries a provenance_status:
live_ingested— values read from the provider’s own published pages, with a field-level evidence trail naming the source URL, selector and raw text.seed_fixture— illustrative values used to exercise the comparison engine while a live adapter is written for that provider. These are not readings of published nutrition and must never be cited as provider claims.
Seed records are labelled as such on every card, provider profile and comparison, and raise a SEED_FIXTURE_DATA validation issue visible in the audit log. Provider-level facts — brand, domain, product format, storage, catalogue model — are researched from each operator’s public site regardless of the meal-level status.
Frequently asked questions
What happens when a brand does not publish a nutrition figure?
KnowDish leaves the value missing and labels it as not published. It is never replaced with zero or an estimate, so it cannot enter a filter, ranking or calculation as if the brand had supplied it.
How does KnowDish calculate protein density?
Protein density is grams of protein divided by published calories, multiplied by 100. If either input is missing or calories are not greater than zero, KnowDish shows a missing input instead of a result.
Can meal-kit and prepared-meal prices be ranked together?
No. A meal-kit price buys ingredients for a recipe the customer still cooks, while a prepared-meal price buys cooked food. KnowDish can display both figures, but marks the price rows as descriptive rather than ranking one format against the other.
Where do KnowDish figures come from?
Live records are read from a provider’s own published pages and carry field-level source evidence. Illustrative fixture records used during development are labelled as examples and must not be cited as provider claims.