What industry knowledge changes in batch management

In container-glass production a recipe is more than a list of ingredients. It determines temperature, redox, cost and what the next shift finds. Modelling it only as form fields loses the order of events: first a version applies, then weighing happens, then the silo is emptier, then the furnace has to suit the calculation, and then the shift hands over. A screen offering every field at once does not know that sequence.

Industry knowledge therefore changes the questions first. What must not disappear after weighing? What does one shift have to leave for the next without anyone recalculating? Which figure still has to be right in the evening after three stations have posted? The answers produce fixed rules, the rules produce the data model, and only then come the screens.

The technical consequences are unspectacular. Postings become traceable events, calculations stay tied to versions, and checking a recipe is a visible step. Migrations and backups belong to the product, and shift start is set centrally. Whether someone can still explain yesterday at six depends on all of this.

Without this knowledge, other mistakes appear, often late. A soft delete that does not put the silo stock back. A recipe change that writes into batches already weighed. A cost calculation that takes the open screen and not the version at the scale. A shift handover that exists only as a comment field. None of it shows in a demo. In operation it adds up.

That is why someone who can explain the process belongs at the start of the architecture work. Acceptance testing notices a missing button. It rarely notices a missing rule. The most expensive mistakes are the ones the system allows because nobody saw them as a domain problem.

My advice to clients and teams: have the working day explained first and the technology after that. If nobody can describe the day, the software will not model it properly either. If they can, the technology is usually the smaller question.