Revisions – why nothing gets silently overwritten
Why every old value stays visible when you correct a recipe or a product.
Published on
Imagine a manufacturer reformulates a product.
You've been tracking your favorite muesli for months, using the clean values printed on the pack. Today you spot the fine print: new recipe, more sugar, less oats. In typical tracking apps what happens next is this: the app picks up the new values and retroactively rewrites your entire logbook. Your stats for last summer suddenly read differently – even though back then you were eating the old recipe.
Same problem from the other direction: two months ago you built one of your own recipes, dialed in, tracked it. Today you want more garlic in the pesto. The moment you save, the app recalculates every old logbook entry that points at this recipe against the new version.
That's a bug, not a feature.
Zutato handles it differently.
When a value changes, a new revision is created. The old revision stays untouched in the dataset. Your muesli entry from last summer still points at revision 1 – with the old values. From today on you log against revision 2 with the new recipe. Both are simultaneously true, because both were historically true.
The same applies to products (when a manufacturer reformulates), to ingredients (when a BLS update lands), and to your own recipes (when you swap one ingredient or rescale a portion).
What you get out of it
- History stays correct. Yesterday's stats remain yesterday's stats.
- You see the change. The product detail lists every revision with date and delta.
- No one quietly shifts values around. Every correction is traceable – even when a manufacturer reformulates.
Sounds like over-engineering for a tracking app? Maybe. For us it was a baseline requirement, after running into too many silently rewritten histories in other apps.