Grounding an AI Coach in Real Data Is the Easy Half

Researchers at Emory published an app this month called NutriCamp, and the interesting part isn’t the app. You point your phone at a meal, or describe it in words, or say it out loud, and it identifies the food, estimates the portion and returns 65 nutrients, the macros plus micronutrients like vitamin D, iron and folate. Plenty of apps do some version of that, ours included. What makes this one worth an essay is the sentence buried in how it was built: rather than guessing nutrition from a model’s memory, the underlying system pairs a multimodal language model with retrieval against USDA’s Food and Nutrient Database for Dietary Studies, the same database the government uses to convert what people report eating in NHANES into actual gram amounts and nutrient values.

That’s a design decision, not a feature, and it’s the correct one. The team’s two papers behind it, DietAI24 in Communications Medicine and a follow-up called NutriMLLM, describe using ten years of population dietary recall data to synthesize 1.1 million image-to-nutrient training pairs, which sidesteps the annotation bill that usually caps this kind of work. Their food reference covers 5,624 foods and beverages and more than 23,000 portion descriptions, the slices and rolls and cups people actually say. Runze Yan, co-principal investigator at Emory’s nursing school, framed the clinical case for it plainly: most existing apps focus on lifestyle, appearance and calorie counting, while a tool built this way can carry enough detail to support disease prevention and management. The whole architecture is a bet that a number retrieved from a real table beats a number a model produced because it sounded about right, and it’s a bet I’d make every time.

Here’s the part nobody puts in the press release. Grounding is a property of how an answer got made, and by the time that answer reaches a user, the property is completely invisible in the text. A retrieved nutrient value and an invented one arrive in the same font. Which means the moment you decide grounding matters, you inherit a second, harder problem: proving, after the fact, that a specific answer actually was grounded. That problem ate a chunk of our week, and it cost us in a way I didn’t see coming.

Mr BITE has a safety net around recipe suggestions. If the model appears to be inventing recipe cards rather than pulling them from a real search, a recovery ladder catches it and replaces the reply. Reasonable idea. The trouble is that the check it ran was a guess about shape, not a check of origin: it read “the model wrote recipe markers but the strict selection step recorded no picks” as evidence of fabrication. In practice that turns out to be the ordinary shape of a perfectly good answer. When the strict picks step comes back empty, the model quotes a candidate’s own identifier from the search it just ran, which renders the identical tappable card. We have the production transcript. On August 19th, in one live conversation, the model wrote two recipe markers, both verbatim identifiers from its own search that same turn, both real. The ladder deleted them and printed a canned “couldn’t find anything” line. The user then asked where the recipes had gone.

That’s a hallucination detector hallucinating. And the failure mode generalises past our particular bug, which is why it’s worth your time and not just ours. A guard that infers grounding from the look of an answer is a style critic. It will reliably flag any correct answer that happens to arrive in an unusual shape, and it will happily pass a confident, well-formatted invention. The fix wasn’t a smarter heuristic. It was recording provenance and actually checking it: every renderable marker in the reply now gets matched against what this turn’s tools genuinely returned, and the guard stands down when they all check out. Ungrounded markers still trip it, which is what the branch was always for.

What makes this expensive is the asymmetry in how the two errors show up. A blocked hallucination is legible: something looked wrong, the net caught it, the log records a save. A deleted correct answer registers as nothing at all. No error, no alert, no line in a dashboard. The only trace is a user staring at a coach that just told them it couldn’t find anything, right after it had, in fact, found something. They don’t file a bug. They conclude the app doesn’t work and they stop opening it. Our false positives were running in production for at least a day before anyone noticed, and we only noticed because a user said so in the chat itself.

So the lesson from Emory’s architecture has a corollary I’d staple to it. Retrieve rather than recall, yes. But then keep the receipt, and make every downstream check read the receipt instead of squinting at the prose. Grounding you can’t verify later isn’t much better than grounding you never did, because the first guardrail you build on top of it will end up guessing too.

BITE of the Week: The Safety Net That Was Eating Real Answers

Version status first. 1.9.0 is cut: the marketing version went 1.8.1 to 1.9.0 on August 18th, and both builds finished the same day on the production profile, iOS build 103 and Android build 134. It carries plan share-by-link and import, the rebuilt saved-plan viewer, verified freezer and meal-prep attributes with filters, full-screen food pictures everywhere, and the rebuilt onboarding middle section. It is not on your phone yet. The store stage hit two of our own tooling bugs on the way out: the iOS release script rejects markdown bold in App Store copy (stores render plain text only) while our process template still showed bold, and the Android script could never actually complete a rollout, because it fetched the whole production track, edited the one release it cared about, and pushed the object back with the previous live release still attached, which Play rejects outright with “Only one completed release is allowed.” Both are fixed. 1.8.1 remains what’s live on both stores until 1.9.0 finishes rolling.

The recipe recovery ladder took two commits to actually fix, and the split is the useful part: the first fixed what the ladder did after it fired, the second fixed why it fired at all. Round one covered three real cases from two live conversations on August 19th. The ladder was overriding the model even when the search had merely hit the personalisation gate, which meant an allergy question the model was politely asking never reached the user. It was discarding usable, macro-backed candidates the model’s own search had already returned before re-searching. And its fallback query was the raw welded user message, device timestamp block and all, so it re-searched for the literal string “No allergies” plus a date stamp. Round two is the grounding check from the essay above. Six deliberate mutations of that commit were each killed by the test suite, and the grounding logic now lives in its own module so it can be tested against the real production payload.

Two more from the same sweep. A transient database read inside the personalisation gate was throwing instead of returning a structured failure, and because the recovery ladder calls that executor directly, one blip in a settings read aborted the user’s entire chat turn rather than degrading gracefully. It’s now inside the try block, with a regression test proving a failed read is never mistaken for evidence that the user needs the allergy question. Separately, a Clerk authentication bug that had been quietly misattributing itself for a while: clerk-js reads navigator.onLine, which React Native never defines, so it treated every device as permanently offline and swallowed failed requests. A network blip during sign-in surfaced as a generic password failure, a bogus Google misconfiguration error, or the app signing itself out while the server session was still alive. All three hit one production device in a single day. Network errors are now rethrown and classified as connectivity problems, token fetches are bounded at 10 seconds instead of clerk-js retrying for roughly 162, and the offline flag is paired with a stored resource cache so a cold start with no signal falls back to the stored client rather than hanging on a loading screen forever.

Also landed and waiting on the next build: comped Pro is now a column payments cannot revoke, which matters because comps previously lived in the same field Stripe rewrites on every webhook, so anyone who had ever started a checkout silently lost their comp on the next foreground sync (six accounts were affected, the founder among them). Saved plan meals can be personalised in place, with the personalised fork offered as a swap into that exact meal. Recipe editing no longer dies on a reply cut off mid-JSON: the token budget doubled and a truncated reply gets one repair pass instead of surfacing as a bare function error. And the log sheet’s keyboard now closes when you tap anywhere that isn’t an input, which sounds trivial until you learn that the return key was previously the only way down.

Three Quick Bites

1. Emory researchers released a dietary assessment app that estimates 65 nutrients from a photo, text or voice, built on retrieval against USDA’s own database rather than a model’s memory. NutriCamp is grounded in the Food and Nutrient Database for Dietary Studies and covers 5,624 foods and beverages plus more than 23,000 portion descriptions, with the underlying work published as DietAI24 in Communications Medicine and extended to micronutrients as NutriMLLM. It’s the study behind the essay above. Medical Xpress

2. Men with the highest ultra-processed food intake had up to a 34% higher risk of prostate cancer in a nationally representative US sample. Researchers at Florida Atlantic University analysed 17,024 men from NHANES between 2003 and 2023, using two 24-hour dietary recalls and the NOVA classification to estimate the share of calories from ultra-processed foods against subsequent self-reported prostate cancer. Senior author Charles Hennekens is careful about what it does and doesn’t show: it’s observational, with self-reported outcomes, and the authors explicitly call for randomised trials to test the hypothesis. The American Journal of Medicine

3. Higher habitual coffee intake tracked with lower body fat and higher skeletal muscle mass in 2,264 Finnish adults. The University of Oulu team analysed the Northern Finland Birth Cohort 1966 at age 46 and found dose-related differences in body fat percentage, fat mass and visceral fat area, alongside lower circulating branched-chain amino acids, markers tied to insulin resistance, while BMI and waist circumference looked the same across groups. It’s cross-sectional, so it cannot tell you coffee caused any of it, and the body composition figures come from bioimpedance rather than direct measurement. University of Oulu

Tool of the Week: USDA FNDDS

Since this issue is about what an AI answer is grounded in, this week’s pick is the thing Emory grounded theirs in. The Food and Nutrient Database for Dietary Studies is USDA’s tool for converting foods and beverages people report eating into gram amounts and nutrient values, and it’s what turns a raw NHANES dietary recall into the numbers that end up in studies like the prostate cancer one above. It’s free, released every two years alongside the national survey data, and the current version is FNDDS 2021-2023, carrying food energy plus 64 nutrients and food components for each entry. For readers: the companion “What’s in the Foods You Eat” search tool lets you look up a food the way a federal dietary survey would code it, portions included, which is a useful sanity check when an app’s number feels off. For builders: this is the difference between a nutrition estimate you can point at a source for and one your model produced from vibes, and it ships as downloadable files as well as through FoodData Central’s REST API. FNDDS at USDA ARS. Free, public, no signup required.

Thanks for reading. If you’d rather your coach showed you where a number came from than guessed confidently, Mr BITE is free on iOS and Android.

Collins, building Mr BITE