If an AI estimates your meal at 720 calories and you know the chicken was only four ounces, who should win?
You should.
That sounds obvious, but it has important implications for how an AI food logger should be designed.
The model never has all the context
A photo does not know:
- that you used one teaspoon of oil instead of one tablespoon
- that the yogurt was 0%
- that you ate half the rice
- that the restaurant menu lists the steak at eight ounces
A text description may omit something visible in the photograph.
The user and the model each hold different pieces of evidence.
AI is useful precisely because it can fill gaps
The value of AI is not that it removes uncertainty.
It can rapidly do work that would otherwise require multiple searches and calculations:
- identify likely foods
- infer components
- propose portions
- map foods to nutrient references
- calculate calories and macros
That creates a strong first draft.
But a first draft is different from a final record.
Food-image research supports caution
Research reviews of AI dietary assessment show considerable progress in food recognition but variability in volume and nutrient estimation.[1][2]
That variability is not surprising. A model is being asked to infer three-dimensional portions, preparation methods and recipe composition from incomplete evidence.
A product should therefore be designed around correction rather than pretending error is impossible.
Editability turns user knowledge into data
Suppose the estimate says:
- chicken: 200 g
- rice: 1.5 cups
- olive oil: 1 tbsp
You know the chicken was 150 g and the rice was one cup.
Editing those assumptions does more than change the total. It creates a record that represents your meal, not the model's generic version of it.
The user should be able to edit at the right level
A useful hierarchy is:
- change the meal total when you have better overall information
- change an item when its portion or macros are wrong
- inspect component reasoning when you want to understand the estimate
Not every inferred subcomponent needs its own persistent editor. More controls can create more confusion than accuracy.
The goal is enough transparency to make meaningful corrections without rebuilding the entire meal manually.
Editability also reduces the stakes of the first estimate
When an AI output is locked, the model has to be right enough that the user can trust it immediately.
When the output is editable, the system can optimize for a different goal:
get close quickly, show the reasoning, and make correction cheap.
That is a much more realistic design target for everyday food.
Estimated and user-confirmed values should not look identical
If the app inferred a number, the interface should communicate that.
If you change the value, it becomes part of your record because you chose it.
This distinction preserves provenance: where did this number come from?
That is especially important when users later look back at trends and assume every historical value had the same quality of evidence.
What if you never edit anything?
That is fine.
The purpose of editability is not to create another mandatory step. It is to provide an escape hatch when the estimate conflicts with what you know.
A good estimate should often be saveable as-is.
The correction path is there for the meals where it matters.
Where Plate Pattern fits
Plate Pattern treats AI estimates as proposals, not commands.
You can inspect the assumptions behind the estimate, change the meal or item values, and then save the record you are comfortable owning.
That design follows a simple principle:
The software can do the arithmetic. The user remains the authority on what they actually ate.
References
- Shonkoff ET et al. AI-based digital image dietary assessment methods compared to humans and ground truth: a systematic review. 2023. PMID: 38060823.
- Zheng J et al. Artificial Intelligence Applications to Measure Food and Nutrient Intakes: Scoping Review. 2024. PMID: 39608003.