Making Food Results Easier to Trust

My goal this month was to make What's On My Food more honest when the information behind a scan is incomplete. During testing, a product high in sugar could still be labeled Healthy. That was a wake-up call: a clean-looking screen is not useful if its verdict disagrees with its own findings. I tightened the score-to-verdict logic and added a completeness check so missing nutrition values cannot quietly produce a confident Healthy result.

I added FDA recall checks for scanned products and items saved in My Pantry, including automatic follow-up checks. The screen now separates “no known match” from “the check could not reach the source.” It offers retry and a link to the official FDA page instead of leaving someone with a false sense of certainty. I also refreshed the phone and tablet layouts, made product findings easier to read, and used official certification artwork only when a badge is verified. Generic dietary labels are marked “Not verified.”

Most of this work used Kotlin, Jetpack Compose, Room, WorkManager, Android Studio, and a protected Node.js backend. I used official FDA and USDA services and Open Food Facts product data while building the source paths. An exact-barcode USDA FoodData Central fallback now exists in backend code, with the API key kept out of the Android app; I still need to verify the hosted configuration before calling that path live. I also stopped Bitwise's animation from running while idle to reduce unnecessary CPU work. I have not measured a faster AI response from that change.

The 1.30.0-rc1 study candidate passed 291 Android unit tests, 70 backend tests, and lint with zero errors. That gives me a strong checkpoint for the work completed this month, but device smoke testing and live hosted USDA verification are still pending, so I am not calling it public-ready.

I finished 40 classroom usability sessions with adult Android users. Participants tried What's On My Food alongside Yuka, Open Food Facts, and Bobby Approved, then rated each experience for usefulness, completeness, ease, and decision confidence. I also asked how likely they were to recommend each app. That gave me two related questions to examine in the thesis: satisfaction-related experience and intention to recommend.

I need to be careful about what this design can show. People compared complete apps; I did not turn the AI explanation on and off within the same app. So the study cannot prove that AI alone caused any difference. The full analysis remains in my classroom thesis. It is not a published or peer-reviewed paper, and I would revisit the classroom-only IRB determination before sharing research results publicly.

I am turning the thesis into a presentation I can explain without reading every slide. My advisor recommended that I show the app architecture and backend flow before the study, introduce recruitment and participant background before the result charts, and keep the slides lighter on text. I am also preparing a short recorded app demo in case the live demo runs into a connection problem.

For the defense, I want to be able to show what I built, why the comparison matters, and where the evidence stops. I will explain the satisfaction and recommendation questions separately and be clear that a claim-level trust-versus-accuracy audit is planned future work, not something this survey validated.

What went right was finding and fixing moments where the app sounded more certain than the data justified, then seeing the study candidate pass its automated checks. What went wrong was a hosted backend container reset that took time to recover from, along with less time for writing than I wanted. Next I will confirm the hosted USDA setup, run device smoke tests on the 1.30.0-rc1 study build, and continue the planned trust-versus-accuracy audit. The project is moving toward final validation and presentation, but it is not public-ready yet.