Food safetyAllergen management
Recipe changes: record what changed and who reviewed the consequences
A recipe change record should identify the old and new versions, the reason, information reviewed and effective date. The important question is not only whether someone edited the recipe, but whether affected instructions and product information were reviewed.

At a glance
A recipe change record should identify the old and new versions, the reason, information reviewed and effective date. The important question is not only whether someone edited the recipe, but whether affected instructions and product information were reviewed.
Define the decision behind the record
Use stable recipe identifiers even when display names change. Separate a draft change from an approved version. Ask the responsible reviewer to identify related records rather than assuming that a recipe edit updates labels, matrices and staff references automatically.
Describe the difference and control its effective version
Identify the recipe and version being changed, then describe the proposed difference precisely. Separate ingredient, quantity, process and information changes so the reviewer understands the scope. Record who proposed the change and which production, label or training records depend on the existing version.
Review consequences against the actual supporting evidence. Document the authorised decision and required updates before the first affected production. Preserve unresolved questions rather than making a new version number appear to approve a change whose supporting work is incomplete.
Set the effective point, communicate the controlled instruction and identify the first affected batch. Test retrieval from a batch made before the change and one made afterwards. Both should show the recipe and supporting information applicable at the time. Keep a declined proposal distinguishable from an implemented revision.
Worked example
A kitchen changes one ingredient in a recurring preparation. The change owner records the old and new references. A reviewer checks the implications, approves a version and identifies which other records need updating before the new recipe is used.
Build a usable record
Use the fields below to capture the facts needed for this particular decision. Keep the actual observation separate from any later correction or approval.
- Recipe identifier and versions
- Changed ingredients or steps
- Reason and supporting information
- Review and effective date
- Related records and communication
Example record and review decision
Fictional record example: RECIPE-04-v2: previous recipe; CHANGE-04: ingredient or process difference; RECIPE-04-v3: reviewed version and effective batch.
Identify precisely what changed and which dependent labels, instructions or records require review.
A new recipe name does not prove that affected allergen information or production instructions were reviewed.
Test the review, not just the form
Choose a batch produced before the change and one after it. A reviewer should recover the appropriate recipe version for each. A later edit must not make the older batch appear to have used the replacement ingredient.
A few useful answers
Should recipes be identified only by name?
A stable identifier and version make the history easier to follow when names or ingredients change.
Does issuing a new recipe version complete every dependent update?
No. Track the affected labels, instructions and team handover separately. The version identifies the change; its supporting review and implementation records show what was actually completed.
Sources and further reading
MarkdownExplore starter templates
Start with a useful checklist
English




