Our Recipe Database Doesn't Know What 'Ultra-Processed' Means Either

On August 10th, HHS and the USDA did something nobody in Washington had managed before: they submitted a proposed federal definition of “ultra-processed food” for final review. Secretary Kennedy framed the stakes plainly, citing HHS’s own figures that nearly 60% of the American diet is now ultra-processed and that childhood obesity affects more than one in five kids. The same announcement proposed making GRAS notifications mandatory, closing the loophole that’s let companies decide for themselves that a new food additive is safe without ever telling the FDA. Two real actions, both aimed at a category of food that researchers have been arguing about since the NOVA classification system was first published in 2009, and that the U.S. government has never once formally defined.

It didn’t sit still for long. On August 27th, Axios reported that sixteen free-market and consumer-rights groups sent a letter to the White House budget office arguing that a federal ultra-processed classification would raise grocery prices by forcing reformulation and repackaging, and urging the administration to block it before the definition even clears review. It’s a real argument, not a bad-faith one, reformulating a product line isn’t free and those costs land somewhere. But it means the most concrete attempt yet to answer “what actually counts as ultra-processed” is now stuck exactly where every previous attempt got stuck: contested, unresolved, and not yet law.

So I went and checked what Mr BITE thinks “ultra-processed” means, expecting to find nothing, and I was right, but not in the way I expected. I grepped the entire app and our backend for “NOVA,” “ultra-processed,” and anything resembling a processing-level field. Zero hits. The Recipe and PackagedFood types carry calories, protein, carbs, fats, fiber and sugar, plus a long tail of spoonacular_* fields for sodium, saturated fat, vitamin C, iron and calcium pulled in from recipe imports. Nowhere is there a field for how processed something is. A homemade lentil soup and a shelf-stable meal-replacement bar with an identical macro split are, to every scoring and coaching system in the app, the same food.

Here’s the part I didn’t expect. Our barcode scanner in openFoodFactsService.ts queries Open Food Facts, the open, crowd-sourced product database that happens to be one of the most widely used real-world implementations of NOVA scoring anywhere, every product it holds that’s been fully annotated carries a nova_group field from 1 to 4, plus a nutriscore_grade letter grade and an ecoscore_grade. Our request to their API is built from an explicit fields= parameter, a literal comma-separated list of exactly what we ask for back. It asks for the product name in five languages, the brand, three different image URLs, serving size, and nutriments. nova_group is not in that string. Neither is nutriscore_grade. We’re not missing this data because it’s hard to get or because Open Food Facts doesn’t have it. We’re missing it because the one line of code that decides what comes back from that lookup was never told to ask for it.

I’m not pretending NOVA is a clean, settled system waiting to be bolted on. Its own architects have spent over a decade arguing about edge cases, an ingredient-count heuristic misses real nuance, and the fact that HHS and USDA are still fighting industry over a federal definition in 2026 tells you the disagreement isn’t just semantic. Adding a badge that says “ultra-processed” to a product page is a real design decision with real consequences for how it reads to a user, and I don’t have that decision made. What I can’t defend is narrower than that: the field already exists, in the exact response body our own code already parses for calories, and we chose not to ask for it. Not a debate. A blank spot in a request string.

BITE of the Week: Notifications Stop Asking Permission to Ask Permission

Version status moved since last issue. 1.11.1 is what’s live on both store listings, App Store lookup confirmed August 31st, and it’s still the native build actually installed on phones. 1.12.0 shipped September 2nd as a JS-only update over that same native runtime, 1.0.3, so it didn’t wait on any store review, it just went out over the air the day it was cut. EAS build numbers for 1.12.0, iOS 107 and Android 138, got logged the same day too, bookkeeping alongside the OTA push rather than a new store submission.

The biggest change in that window wasn’t a bug fix, it was a founder decision recorded straight in the commit from September 1st: turn notifications on by default and stop treating explicit opt-in as a prerequisite for the one thing that actually gets people to open the app. The old flow had a real trap in it, the onboarding quick-setup screen force-wrote engagement: false for anyone who simply didn’t touch that row, permanently muting users who never made an active choice either way. That’s gone. Now granting the OS permission is the consent; the app’s own master mute and the phone’s own settings are the only opt-outs, and a user who explicitly set engagement: false in the past still has that honored. Every user gets one real OS permission dialog once onboarding finishes, no priming alert first, no carve-out by coaching tier, and a new one-shot key so people who dismissed the old priming alert still get the real one. On the server side, a new log_nudge pipeline went live the same day: established users, day 14 and past, get a missed-yesterday morning nudge or a nothing-logged-yet midday nudge, decided deterministically in the hourly coach scan from the actual meal-plan data, authored from a template pool with no model call involved, one per user per local day, still bound by the quiet-hours window and the 12-hour interruption budget.

Three smaller fixes rode the same window. A Delish import had stored “1/2 c. chicken broth” with the ingredient name literally starting with “c.”, because no parser recognized the dotted abbreviation for cup, one recipe plus its community cache copy were affected in prod; every parser in the pipeline, plus the shopping-list unit aliases, now accepts “c” and “c.” as cup. The “Cooking for” recipe stepper used to be a whole-batch multiplier that could only go up, four portions could become eight or twelve but never three, it now sets the total portion count directly from 1 to 99 in either direction. And the DeepSeek-backed proactive coach assessments, which had gone empty or truncated three times in two weeks from what looks like a v4 reasoning-token burn, now get one automatic retry with thinking disabled, the one setting that reliably comes back clean.

Three Quick Bites

1. Eli Lilly agreed on August 31st to acquire Merida Biosciences for up to $2.875 billion in cash, its 13th acquisition of the year, to get at Merida’s biologics that selectively degrade the disease-causing autoantibodies behind conditions like Graves’ disease and food allergy. It’s a deliberate move by the company that makes Zepbound and Mounjaro to build a second pillar in autoimmune and allergic disease, not just deeper into weight-loss and diabetes, and it’s a reminder that the GLP-1 giants are already spending their windfall on what comes after. Bloomberg

2. A PNAS study published August 11th used Britain’s abrupt 1953 end of sugar rationing as a natural experiment on 64,761 UK Biobank participants and found that people whose first 1,000 days fell under rationing had 36% to 69% lower rates of several cancers decades later, plus longer telomeres equivalent to roughly 2.2 fewer years of biological aging. It’s observational, built on a historical policy shift rather than a controlled trial, but the sample size and natural randomization make it one of the cleaner looks yet at what early-life sugar exposure actually costs over a lifetime. ScienceDaily

3. A mouse study out of the Universidad de Chile, published in Frontiers in Nutrition and covered August 30th, fed sucralose or stevia to one generation of mice for 16 weeks and found altered gut microbiomes and changed metabolism and inflammation gene activity, with some of those changes still detectable in offspring and grand-offspring that never touched either sweetener. Sucralose left the stronger, more persistent signal; stevia’s effects were more prominent in the first generation and faded by the second. It’s mice, not people, and it’s one lab’s dosing protocol, but a multigenerational signal from a zero-calorie sweetener is exactly the kind of finding that deserves a human follow-up before anyone treats it as settled either way. ScienceDaily

Tool of the Week: Open Food Facts

Since this issue is about a field our own barcode lookup doesn’t ask for, this week’s pick is going straight to the source. Open Food Facts, the free, crowd-sourced product database our own app already queries, shows its NOVA processing group and Nutri-Score letter grade right on the product page for any barcode you scan through their own site or app, no account needed. Before you assume a packaged food is fine because the calorie count looks reasonable, scanning it there directly gets you the processing-level read our own lookup currently skips. For readers, it’s a real free second opinion sitting one barcode-scan away. For builders, it’s proof the data isn’t hard to get, it’s already sitting in the same JSON response you’re parsing for calories, whether you ask for it is a one-line decision. Open Food Facts. Free, open data, no signup required.

Thanks for reading. If you’d rather your coach’s database asked the same questions the FDA is finally getting around to, Mr BITE is free on iOS and Android.

Collins, building Mr BITE