Revisions – why nothing gets silently overwritten
Why every old value stays visible when you correct a recipe or a product.
Published on
Imagine you got a carrot entry wrong.
In typical tracking apps it works like this: you create "carrots" at 100 kcal/100 g, track carrots for two weeks, realize the value should have been 41 kcal, and fix it. What happens? Every entry in your logbook that references those carrots is retroactively recalculated against the new value. Last week's stats now read differently than they did yesterday.
That's a bug, not a feature.
Zutato handles it differently.
When you change a value, a new revision is created. The old revision stays untouched in the dataset. Your carrot entry from last week still points at revision 1 – with the 100 kcal. From today on you log against revision 2 with 41 kcal. 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.