If you’ve ever tried to keep an allergen matrix in a spreadsheet, you already know how it fails. It isn’t the first version that catches you out — the first version is usually fine, built carefully over an afternoon. It’s the tenth change three months later: a new special, a swapped supplier, a bun that quietly became a brioche. The menu moves and the grid doesn’t, and now the document that’s supposed to protect you is lying.

The problem isn’t effort. It’s structure. A matrix treats allergens as a separate thing you maintain alongside the menu, which means every menu change is really two changes — and the second one is the one that gets forgotten. The fix is to stop keeping allergens beside the menu and start keeping them inside it.

Set it once, inherit it down

The core idea is that an allergen is a property of an ingredient, and everything an ingredient touches should inherit it automatically.

• Set allergens at the product level. A dish declares what it contains once. You’re not re-entering “milk” on every item that has cheese — you’re setting it where the cheese actually is.
• Let variants inherit. A large and a small of the same dish share allergens. A different size isn’t a different declaration, so it shouldn’t need re-entering. Variants should carry down what the parent product already knows.
• Change the source, not every copy. When an ingredient’s allergen profile changes, you want to update it in one place and have every dish that uses it update with it. The whole point of inheritance is that there’s a single source of truth, not fourteen copies to chase.

This is the difference between allergen data that decays and allergen data that holds. In a spreadsheet, accuracy depends on you remembering to update every affected cell. With inheritance, accuracy is the default and you have to actively break it to get it wrong.

The cheese-on-everything problem

Here’s the gap that catches most people, because it’s invisible until someone gets hurt: modifiers add allergens.

Your margherita is declared correctly. Then a customer adds anchovies (fish), a different cheese (milk, already there), and a garlic dip (possibly egg, possibly mustard). The base pizza’s declaration was right. The order’s declaration is now wrong, because three allergens walked in through the modifiers and nothing caught them.

• Attach allergens to modifiers, not just base products. “Add cheese” carries milk. “Brioche bun instead” carries egg and often sesame. “Peanut satay” carries the obvious. If your allergen data stops at the base dish, every add-on is a hole in it.
• Let the final order reflect what was actually built. The declaration a customer sees should account for what they’ve added, not just what they started with. A dish is safe or unsafe as ordered, and add-ons change the answer.
• Watch the swaps as well as the adds. Swapping one component for another can remove an allergen or introduce one. A gluten-free base removes wheat; a different sauce might add soya. Both directions matter.

Modifiers are where allergen management quietly falls apart, precisely because the base menu looks correct. It’s worth auditing your add-ons specifically — they rarely get the same attention as the dishes.

”May contain” is not the same as “contains”

There are two honest statements you can make about an allergen, and they mean different things.

• Contains — the allergen is an ingredient. It’s in there on purpose. This is a firm, factual declaration.
• May contain — the allergen isn’t an ingredient, but you can’t rule out cross-contamination. Shared fryers, shared surfaces, flour in the air. This communicates a risk you can’t fully control, not a recipe.

The two aren’t interchangeable, and blurring them cuts both ways. Slapping “may contain nuts” across the entire menu as a blanket disclaimer trains customers to ignore it — the allergy-aware ones learn it means nothing and stop reading it, which defeats the purpose. But failing to flag genuine cross-contamination risk is the more dangerous error. The useful version is specific: this dish contains X; this dish may contain Y because of how the kitchen works. Precision is what makes the declaration trustworthy.

Keeping it accurate when the kitchen changes

Allergen data doesn’t go wrong all at once. It rots slowly, one small change at a time, and the failures are always the same handful:

• New menu items launched without allergen data. The dish goes live; the declaration doesn’t. A quick check that no product is missing allergen information catches this before service does.
• Supplier swaps that change the profile. The “same” ingredient from a new supplier may carry a different allergen or a different cross-contamination risk. A changed supplier is a prompt to re-check, not a like-for-like.
• Recipe tweaks nobody logged. A thickener added, an oil changed, a garnish introduced. Small in the kitchen, significant on the label.
• Modifier gaps. As above — the add-on that never got its allergens set, sitting quietly available on every order.

The way to stay on top of it isn’t heroic diligence, it’s a short routine: whenever a dish, ingredient, supplier or modifier changes, the allergen data is part of the change, not a follow-up task. When allergens live inside the menu, that’s a natural habit. When they live in a separate spreadsheet, it’s a second job that always loses to a busy service.

A good allergen setup isn’t the one with the most disclaimers. It’s the one where getting it right is the path of least resistance — where the declaration updates because the menu updated, and the only way to make it wrong is to go out of your way. That’s the whole game: making accuracy the default instead of a thing you have to remember.