Naming a dish is the easy half of the problem
An image model can tell you a plate holds bandeja paisa with reasonable confidence, because the ingredients and plating are visually distinct. Estimating how many grams of rice, beans, chicharron and avocado are actually on that plate is a different and much harder problem, because portion size varies by household, by restaurant, and by how the food is stacked in the photo. Most public discussion of food-recognition AI treats identifying the dish as equivalent to measuring the dish. Those are different claims, and a nutrition data system that reports them the same way is reporting more confidence than it has earned.
I work on the data side of Comi AI, a food-logging app built for Latin American cooking, and portion estimation is where most of the engineering effort actually goes, not dish recognition.
A regional food database inherits the gaps of its source data
Comi AI's Colombian nutrition data is sourced from the ICBF and the TCAC, Colombia's national food composition table, rather than a generic international database extended with guesses, the same underlying data behind the app's public calorie table. That distinction matters structurally. A national composition table reflects the preparation methods, ingredient ratios and regional variants actually eaten in that country, where a repurposed generic database reflects whatever country built it first. Extending a database from one country's cuisine into another's is not a matter of translating dish names. Sancocho in one country and sancocho in another can carry different base ingredients entirely, and a system that assumes one recipe standard for a dish name across nine countries, Mexico, Colombia, Argentina, Peru, Chile, Venezuela, Ecuador, Spain and the United States, builds in error before a single photo is scanned.
Offline is a data integrity problem, not just a UX one
A scan taken with no connection has to be queued and processed correctly once the device reconnects, without dropping the entry or double counting it against a sync retry. Comi AI's offline queue exists because a meal-logging system loses trust the moment a user scans lunch on a train with no signal and the entry never appears. From an informatics standpoint, that queue is doing real work: holding state client side, reconciling it against a server side timestamp, and resolving conflicts if the same device queues the same scan twice.
Data protection decisions that never show up in a demo
The underlying data lives in Supabase with encryption in transit and at rest, and row level security scoped per user, with in-app export and deletion of all personal data. None of that is visible in a screenshot of a calorie estimate, but it determines whether a health-adjacent product can be trusted with years of someone's eating history. A food-logging database that cannot cleanly export or delete a user's own data is not ready to hold sensitive behavioral data at scale, no matter how good its recognition model is.
The honest posture is itself a data decision
Comi AI's own FAQ states that an estimate can contain errors, should be reviewed before saving, and is not a substitute for guidance from a nutrition professional. Building that disclosure into the product, rather than leaving it in a terms of service page nobody reads, is a design choice about how confidently a probabilistic system should present its own output. A health informatics system that reports a calorie estimate as fact rather than as an estimate is making a claim it cannot support.
Naming a dish, measuring a portion, sourcing the underlying composition data by country, and disclosing the uncertainty in the final number are four separate engineering decisions. A system that treats them as one decision, made once, is the one that starts producing confidently wrong numbers the first time a user in a country the model was not built around opens the camera.