Methodology

Every scan runs through the same four-step pipeline. First, a headless browser visits the restaurant’s menu URL and captures the rendered HTML, including the dishes that lazy-load after page paint. Second, a parser walks the DOM and extracts a structured record per dish - name, ingredient list, allergen tags, price, and category - matching the most common schema patterns we have seen across thousands of restaurant menus. Third, a language model audits each dish against a vegan rule set built from years of menu reading. The audit produces a confidence score based on how well the ingredients are documented. Fourth, the scan caches its results in our database so the next visitor to the same restaurant gets the same answer in under a second.

None of the four steps is a black box. We log the captured menu HTML, the parsed dish records, the language model’s reasoning trace, and the final order script committed for every item. That matters because it means a wrong answer is diagnosable rather than mysterious: we can tell whether the browser captured a stale menu, whether the parser dropped an ingredient line it should have caught, or whether the model read a documented ingredient correctly and still reached the wrong conclusion. Those are three different bugs with three different fixes, and without the trace they would all look identical from the outside.

What is not in that pipeline: a person. Every step above is automated. We built the schema for human review and it is wired into the product, but the number of items a person has reviewed is currently zero, and we would rather say so here than let the word “verified” imply otherwise. That is also why every order script ships with counter-side checks: the server is the human in this loop, and right now they are the only one.

The primary source is the restaurant’s own menu page. When that page publishes structured allergen data - a public allergen PDF, an in-page allergen table, schema.org markup with ingredient fields - we read it and treat it as the highest-confidence input. For chains that publish detailed allergen sheets (Chipotle, Taco Bell, Panera, P.F. Chang’s, Sweetgreen), the documented allergen status is essentially the source of truth and the model’s job is mostly to write the order script in the language the kitchen will actually ring.

When the menu page does not publish allergen data, the scan falls back to ingredient inference: read the dish name, read the description, cross-reference common recipes, and assign a confidence score that reflects the gap between documented and inferred. An item described as “black bean burrito with rice and salsa” on a page with no allergen sheet still earns a high vegan confidence because the ingredient pattern is unambiguous. An item described as “chef’s special vegetable bowl” on the same page earns a low confidence because the dish name does not commit to specific ingredients.

We use vegan in the practical sense: no animal-derived ingredients in the dish as ordered, including no dairy, no eggs, no honey, no fish, no shellfish, no broth or stock derived from animals, and no animal-fat cooking medium. Shared-equipment cooking (a fryer used for both fries and chicken, a grill used for vegetables and steak) is flagged as a counter-side check rather than disqualifying, because most vegan diners we have spoken to treat shared-equipment cooking as personally acceptable while ingredient contact is not.

Honey is treated as non-vegan by default per the dominant North American vegan convention, but every honey-containing item is explicitly tagged so a vegan who eats honey can override the recommendation. The same explicit-tag pattern applies to wine and beer used as cooking ingredients, fish sauce and oyster sauce in Asian preparations, and gelatin-thickened sauces.

We are not a medical-allergen reference. If you have a clinically diagnosed dairy or egg allergy, the canonical source for what is in any dish is always the restaurant itself plus a conversation with the kitchen. Vegan Recon is a research aid that gets you to the right question to ask, not a substitute for that question.

Every item carries a confidence score between zero and one. The score measures how well documented the ingredients are, and nothing else. A score above 0.85 means the scan resolved the item against a documented ingredient list: a chain allergen sheet, a published recipe, or ingredient markup on the menu page itself. A score between 0.5 and 0.85 means the scan inferred the vegan status from dish naming patterns and recipe norms; the item is probably vegan but a counter-side check is worth it. Below 0.5 we usually do not surface the item at all - if you see one, treat it as a lead.

No score means a person checked. Human review is tracked as a separate flag, not as a confidence band, and today that flag is set on zero items. A high score means the paperwork was good, not that anyone stood at the counter and confirmed it. When human review does start, it will show as its own badge rather than being folded into this number.

Three places. First, local restaurants without a structured online menu - the scan does its best with whatever the page shows, but a hand-typed paragraph menu without ingredient details is hard to verify against any rule set. Second, regional chains that change their ingredient suppliers between markets - the corporate allergen sheet may say one thing while the specific store you walk into uses a different supplier whose recipe we have not catalogued. Third, anywhere the kitchen reformulates a dish faster than the website updates - this happens at every chain we cover, and our weekly re-verification cron catches most of it but not all.

When you order a Vegan Recon-flagged item and the kitchen confirms something the scan missed - a hidden butter brush, a new chicken-stock base, a swapped supplier - send us a correction by email. Every correction trains the next round of scans, and the rule-set adjustment lands on the affected items across the whole catalogue, not just the dish you reported. The contact line is on the About page.

Every chain page carries a “Menu checked” date stamp at the top. It records when our scan last read the menu, not when a person last looked at it. A weekly cron re-fetches every cached restaurant menu and re-runs the audit; the stamp updates on each successful run. When a chain rolls out a menu change that the cron picks up, the affected items’ confidence scores drop temporarily and surface a re-verify note until a human curator confirms the new state.

Local restaurant menus get a re-verify pass every 30 days because they change less often than national chain menus. If you scan a local restaurant whose menu you know changed recently, the scan respects a fresh re-scan request and ignores the cached state. The result then enters the normal weekly cron cycle from the new baseline.