MenuBridge · Create a New Kind of Experience

How MenuBridge works

A menu that rewrites itself for the person holding it, takes their order in their own words, and hands the kitchen a ticket in Italian. This page is also our track compliance statement.

The problem

Rome had 22.9 million tourist arrivals in 2025. Most of them can't read an Italian menu, and anyone with an allergy has to trust a rushed translation or a busy waiter. Staff spend minutes per foreign table explaining dishes, and mistakes reach the kitchen.

How it works

  1. Diner on a phone

    Scans the QR code, picks a language and any allergies or diet, orders in their own words, and confirms before anything is sent.

  2. MenuBridge app

    Next.js on Vercel. Sends the menu data and the order to the model, validates every answer, and logs latency, tokens and euros.

  3. Gemma 4 on AMD Instinct MI300X

    vLLM on ROCm, one GPU. Writes dish explanations, maps the order to dish IDs and translates notes into Italian.

  4. Allergen and diet check

    Fixed rules, no AI. Every dish is checked against the owner-approved ingredient sheet; unknown dish IDs are dropped and clashes are removed with the reason.

    Fed by the ingredient sheet: allergens per ingredient, approved by the owner dish by dish.

  5. Kitchen ticket

    Always in Italian, with the allergy line in red. A waiter confirms at the table and the status goes back to the diner's phone.

What is created

What the model generates, and what it never decides

Gemma 4 generates

  • dish names and explanations in 8 languages, styled for 4 audiences
  • the mapping from free text to dish IDs
  • constraints the diner mentions (“no pork”, “allergic to fish”), which only ever add restrictions
  • notes translated into Italian for the kitchen
  • a draft ingredient sheet when importing a new menu, which the owner must approve

It never decides

  • which allergens a dish contains
  • whether a dish fits a diet
  • whether a dish is safe for a diner
  • what reaches the kitchen: code checks every line again before the ticket is built

Allergens and diets come from fixed rules over the restaurant's own ingredient sheet.

Quality control

Fixed-rule gate
Allergens and diets are computed from the ingredient sheet by code (lib/gate.ts), never by the model.
Dish-ID enums
The model can only name dishes and ingredients that exist: JSON-schema enums in every request, and the server drops unknown IDs.
zod validation
Every model answer is validated. On failure it is retried once with the error, then the app falls back to a safe deterministic answer.
Claim guard
Descriptions that say “gluten-free”, “safe for”, “vegan” and similar, in 8 languages, are rejected and regenerated once; then the restaurant's Italian text is shown.
Owner approval
A dish the owner has not approved shows “Ask staff about allergens” and never passes for a diner who declared an allergy or diet.
Waiter confirmation
Every ticket is confirmed at the table before it counts as an order.
AI labels
Every AI-written text carries an “AI-generated” label.

Cost per experience

Every model call shows its own cost in the footer and in the AMD panel. The per-experience figure appears here once the benchmark below has been run on the MI300X.

Who pays

The restaurant pays a monthly subscription; diners pay nothing and install nothing. We will test €29 a month with the pilot. The gain for the restaurant: fewer staff minutes per foreign table, fewer order mistakes, and allergen questions answered without staff.

Pilot: we are asking a trattoria near Link Campus in Rome to try it free for 30 days with its own menu and ingredient sheet.

Benchmark on AMD Instinct MI300X

No benchmark yet. Run npm run bench against the MI300X droplet and commit bench/results.json.

AMD stack

Licence

MIT licence. Source code: github.com/feedddosever/amdgimmemyaccess.