Food Allergy Navigator

Our service helps people with food allergies or dietary restrictions find suitable dishes, share their profile with restaurants, and communicate safely abroad with built-in translation.

Comment

Inspiration

My child was diagnosed with a wheat allergy at a young age and has been taken to the hospital by ambulance several times after accidentally consuming wheat. These incidents resulted from various causes, including parental mistakes and failures in school meal management.

Food allergies can be life-threatening, yet awareness remains low among people who are not directly affected, and many organizations provide only the minimum support required by law. Dining out while traveling is especially frightening, and international travel presents an even greater challenge. I started building this app to reduce that fear and inconvenience.

What it does

Before Build Week, I had already created a simple prototype. Users could create an allergy profile and filter suitable menu items using allergen information published by major restaurant chains.

During Build Week, I expanded the app so users can share their allergy profile with hotels and restaurants in advance and discuss suitable menu options before visiting. GPT provides translation when the parties speak different languages, but because these messages may contain life-critical information, the original text is always preserved and nothing can be sent without explicit human approval.

The system is also designed to support MCP connections, creating a future path where AI agents can discuss menu options and make reservations on the user’s behalf.

How we built it

The application uses Next.js 14 App Router and next-intl, with Japanese and English URL prefixes. The standalone build is deployed to a VPS using PM2 and Nginx.

All safety-critical decisions—including mode control, scope, consent, conservative classification, expiration, and human approval gates—are handled by deterministic code rather than delegated to GPT. Because errors could have life-threatening consequences, AI never makes the final decision. The original text is preserved, and final judgment always remains with a human.

Challenges we ran into

One of the biggest challenges was deciding how much we could trust AI output.

GPT’s constraint extraction sometimes produced errors where the quoted text was correct but the classification was wrong—for example, quoting “soy” while normalizing it as “peanut.” Verifying that a quotation exists in the source text was therefore not enough.

We implemented deterministic checks to confirm that each quotation actually refers to the identified allergen. We also added contextual checks for negation, such as “I am not allergic to peanuts,” and preferences, such as “I prefer peanut-free dishes.”

Accomplishments that we're proud of

We still need to establish partnerships with hotels and other hospitality providers, but we successfully built the foundation for securely sharing allergy information and discussing suitable meals in advance.

We are also proud of the MCP implementation. It allows users to access the service through the AI agents they already use, without forcing them to create and log in to another application. We believe this provides a more natural and accessible interaction path.

What we learned

We learned that verifying quotations alone cannot prevent AI misclassification. Grounding—confirming that a quotation exists—and semantic cross-checking—confirming that it actually supports the classification—are separate requirements. Only by implementing both could we prevent the system from making automated decisions based on the wrong allergen.

We also found that cross-checking AI-generated implementations with AI-based reviews was highly effective. Reviewers from different model families identified issues that humans could easily overlook, including missing connections in real user interface flows and writes occurring outside the protected scope of a lock. They also provided concrete reproduction steps. In particular, the review process reaffirmed the robustness of Codex.

What's next for Food Allergy Navigator

The next step is MCP Stage 2: public authorization using OAuth 2.1. The design is complete, but implementation will begin only after completing requirements for rate limiting, legal review, audit retention, token rotation, and other security measures.

We also want to enable real consultations with hotels. The current version is limited to a demonstration using fictional data. Before operating with real businesses and exchanging actual messages, we need to clarify and satisfy the relevant requirements under Japan’s Radio Act. After completing that process, we plan to move on to real-world operational testing.

What's new during Build Week

The base Food Allergy Navigator existed before Build Week (baseline commit 43b7f6d, dated June 11, 2026).

Newly built during Build Week, beginning July 13, 2026:

The complete Hospitality Copilot v2: a bilingual consultation workflow covering profile sharing, consent, constraint analysis, menu evidence, human-approved messaging, resolution, and expiration or revocation. MCP Server Stage 1, including 15 tools, a token store, and audit logging, plus the Stage 2 OAuth design. A complete i18n overhaul, including URL-based locale handling as the single source of truth, four-layer coverage testing, and official English translations for 29 regulated allergen items. The complete grounding-verification pipeline and security-hardening implementation.

Built With

Share this project:

Updates