Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Allergen checker series ~5 min read

What happens when a supplier changes a recipe

This is the failure mode that keeps people awake, and it is entirely invisible to a process that checks allergens when a recipe is written.

Key takeaways

  • A product code staying the same does not mean the product did.
  • Store every specification version; comparison is only possible against a stored one.
  • Specifications expire. An old one becomes unknown rather than staying valid.
  • Flag the affected dishes by name, and keep the flag open until a person clears it.
  • A supplier switch is the same event and is more common than a reformulation.

How it happens

How a supplier reformulation changes a dish with no visible signalA horizontal row of five boxes. Same product code: same order, same price. Reformulated by the manufacturer. New spec issued by email, or not. Delivery looks identical and nobody notices. The dish changed, with no event. A note says every step here is normal commercial behaviour and none of it is anybody's failure.THE CHANGE WITH NO SIGNALSame product codesame order, same priceReformulatedby the manufacturerNew spec issuedby email, or notDelivery looks identicalnobody noticesThe dish changedwith no eventEvery step here is normal commercial behaviour. None of it is anybody's failure.
Fig 1. How a dish acquires an allergen without anybody deciding. Nothing in this sequence is unusual, which is why it needs a system rather than vigilance.
  • Compute
  • Management
  • Front-end & mobile

Why the product code stays

Changing a product code has commercial costs: catalogues, customer ordering systems, shelf labels. A manufacturer improving a formulation, changing a supplier of their own, or reducing a cost will frequently keep the code and issue an updated specification.

That is entirely legitimate and it means the code cannot be used as a proxy for the product being unchanged. The specification document is the thing that changes, and it has to be compared rather than filed.

Comparing

How an arriving specification is compared with the stored versionA vertical chain of five steps entered by a box labelled A specification arrives for a known ingredient. Step one asks whether any stored version exists for this ingredient; if not it exits to First one, stored with no comparison. Step two compares all fourteen allergens state by state. Step three asks whether anything was added under contains or may contain; if not it exits to a further check for anything removed, which is also worth flagging. Step four identifies which dishes are affected through the recursion. Step five flags them by name, open until cleared. A note says removals are flagged too, because a dish that was excluded may now be available.AWS ACCOUNTA specification arrivesfor a known ingredientAny stored version?for this ingredientFirst onestore it, no comparisonnoCompare all 14state by stateAnything added?contains or may containAnything removed?also worth flaggingnoWhich dishes?through the recursionFlag them by nameopen until clearedRemovals are flagged too: a dish that was excluded may now be available.
Fig 2. How a new specification is processed. Comparison against a stored version is the whole mechanism, which is why specifications are versioned rather than replaced.
  • Compute
  • Database
  • App integration
  • Management
  • Analytics

Removals matter too

A reformulation that removes an allergen is good news and it is also a change that should be reviewed rather than applied silently. It may mean a dish can be offered to people it previously could not, which is worth acting on deliberately.

It also occasionally means the specification is less complete rather than the product being different, which is exactly the sort of thing a person should look at.

Specifications expire

The age profile of ingredient specifications across a menuA stacked bar chart with four bars. Two series: ingredients with a current specification in green, and those treated as unknown in orange. Zero to twelve months: sixty-one current. Twelve to twenty-four months: twenty-four current. Over twenty-four months: nineteen treated as unknown. None held: fourteen treated as unknown. A note says thirty-three ingredients are unknown and that number is the system's main work list.020406080~610-12 months~2412-24 months~19Over 24 months~14None heldIngredients with a current specTreated as unknownThirty-three ingredients are unknown. That number is the system's main work list.
Fig 3. The age profile of a menu’s ingredient specifications. Anything beyond the expiry becomes unknown, which converts a silent risk into a task.

Expiry is a deliberate discomfort. A specification from three years ago may well still be accurate, and there is no way to know, so treating it as unknown is the honest position and it produces a steady, manageable stream of requests to suppliers.

The expiry period is a judgement, set once, visible in configuration. Two years is defensible for a stable ingredient; a shorter period is appropriate for anything manufactured to a formulation that changes.

Supplier switches

More common than reformulations and structurally identical: the same ingredient, a different manufacturer, a different specification. Where the purchasing system records which supplier delivered, the check happens automatically; where it does not, a delivery from a new supplier is a manual event that has to be entered.

This is also the point where the yield finding from Day 123 and this one meet: a supplier switch changes cost and allergens at the same time, and only one of those is usually noticed.

Next: what the system will not tell you.

All posts