This is a design concept, not a live system — the exchanges above are illustrative. What it shows is the one mechanism that matters: retrieval-only answering. Each dish has a curated record — ingredients, allergens, whether it's a signature — and the agent answers only from that record. If a question maps to a known dish, it answers from the table; if the dish, ingredient or confidence isn't there, it says "I'm not sure — please ask staff" rather than inferring. Languages are handled at the model layer; the facts are not. The whole point, for allergens, is that it would rather defer than guess.
On the roadmap
- One verified source of truth. The allergen and ingredient table is hand-curated and owned by the kitchen — a single record per dish that every language reads from, so the Tamil answer and the English answer can never disagree. Get the data hygiene right and the answers follow.
- Defer by default. Severe allergies and any low-confidence match route to a person — the agent states what a dish contains but never certifies it safe. Cross-contact is a kitchen judgement, never a chatbot's. This is the line a confident "100% nut-free" bot crosses and we don't.
- A fifth language for the tourist segment. Japanese alongside the four official languages, matched to the device's locale on scan — the menu opens already in the guest's language.
- Sit on SG-native plumbing. Buy the QR ordering and PDPA-resident data from a local player (Qashier, Oddle); keep the guardrailed Q&A layer as the part worth building, because no off-the-shelf tool ships the refusal behaviour.
- Everything logged for the quality layer. Every answer, every "ask staff" deferral and every escalation is recorded for UC12 — health-sensitive query text minimised under the PDPA — so the safety behaviour is measurable, not a promise.
Full use-case write-up — the problem, benefits and vendor landscape:
UC10 — Multilingual menu Q&A →
Concept mock-up — illustrative data, not a live system.