BrauMo BrauMo ← Blog

How it works · 6 min read ·

Editing a recipe should not change last month's batch

A recipe in a brewery is two different things at once: the formula being brewed to today, and the record of what a finished batch was actually made from. Most software stores only the first, which quietly rewrites the second every time a recipe is corrected.

The failure is silent, which is what makes it serious

Consider an ordinary week. A ginger flavour is dialled in at 6 grams per litre. Fifteen batches are brewed across the spring. In June the ginger supplier changes and the dose is lowered to 5 grams to match. Nothing dramatic happens, and nothing appears to break.

But if the recipe is a single editable record, all fifteen spring batches now claim they were made at 5 grams. No warning is raised, because from the software's point of view nothing went wrong: a field was edited, and every page that reads it shows the new value. The batch record has been altered months after the fact by an edit that had nothing to do with it.

That matters in three separate places. A customer complaint about a spring bottle is investigated against the wrong formula. A cost per litre calculated for the spring is quietly restated. And an auditor asking what a specific batch was made to gets an answer that is confidently wrong, which is worse than an answer that is missing.

Master recipe and control recipe

Process industries settled this a long time ago. ISA-88, the batch control standard, separates the master recipe, which is the current formula for a product, from the control recipe, which is the copy bound to one specific run. The master is meant to change. The control recipe is meant never to change, because it is evidence rather than instruction.

Applied to a small kombucha brewery, that means a batch should record the version of the recipe in force at the moment it was created, and keep reading that version afterwards. Correcting the master then does what it should: it changes what the next batch will be brewed to, and nothing else.

In BrauMo a batch binds to its recipe version when it is created, and a recipe that has never been versioned gets a first version cut at that moment, so no batch is ever left pointing at nothing.

A snapshot has to be the whole recipe

The tempting shortcut is to snapshot only the fields that matter: the doses, perhaps the tea blend. It works until the day something else starts reading the recipe.

A snapshot scoped to today's readers stops being a snapshot as soon as a new reader appears, and the failure mode is the same silent one as before. The new reader finds no snapshot value, falls back to the live master, and the batch record starts telling the truth about some fields and the present about others. Nobody sees a mixture happening.

The version has to hold everything: every column of the recipe, the tea blend with its shares, and the flavour ingredients with their quantities and units. Sorting matters too, or two identical blends stored in a different row order compare as different and cut a pointless new version on every save.

Versioning must never stand between a brewer and Save

Two smaller decisions matter as much as the concept.

The first is that a version is written inside the same transaction as the change it describes. If the save fails, the version goes with it, rather than leaving behind a record of a state that was never stored.

The second is that versioning is a record about a change, never a precondition for it. If cutting a version fails for any reason, the save still goes through and the next successful save covers both edits. A brewer standing at a tank must always be able to write down what is true. Software that refuses a correction because its own bookkeeping is unhappy has misunderstood which of the two is load-bearing.

One more detail: pressing Save without changing anything compares against the last snapshot and writes nothing. Otherwise the history fills with identical versions and stops being readable, which is a slower way of losing the same information.

The ingredient a brewery makes itself

Versioning has a close relative in material planning, and the same principle drives it: a record is only useful if it goes all the way down.

Many kombucha producers make some of their own inputs. An acidifier is the clearest case. A flavour recipe might draw 40 millilitres per litre of it, and that acidifier is not a purchased ingredient but a recipe of its own, fermented over about seventy days out of tea, sugar and starter.

Planning that stops at the flavour recipe reports that 40 litres of acidifier are needed. That statement is true and nearly useless. The tea and sugar the acidifier itself consumes were never added to the buy list, and the seventy days of lead time never appeared in any schedule. The shortage is discovered on the day the flavour run was supposed to happen.

An in-house ingredient therefore has to be exploded one level further, so that planning a flavour run also demands what the acidifier needs and shows when it has to be started. One level, deliberately: the depth a brewery actually has is a flavour built on a culture, and a recursive walk would need its own cycle guard for a case that does not occur in practice.

What to ask of any system

These are two specific answers to one general question, which is worth putting to any brewery software before trusting records to it.

None of this is exotic, and none of it is unique to kombucha. It is simply the difference between a recipe as a working document and a recipe as evidence, which is a distinction any brewery ends up needing the first time somebody asks a precise question about an old bottle. Batch records depend on it, and so does tracing a lot back to what went into it.

BrauMo versions recipes automatically, binds every batch to the version it was brewed from, and explodes in-house ingredients into their own requirements and lead times. Nothing to switch on, and no batch record changes after the fact. Take the product tour →

Related reading

See how BrauMo handles this: Take the product tour → · See pricing →