From the batch sheet through the batch log to the daily log

The batch sheet sets out what goes into the furnace: which recipe version, which target batch, which redox position. The daily log records what came of it: which batches ran, what the shift leaves for the next and whether the day is closed. On paper those are two separate documents. In software they should not stay that way.

The problem looks harmless at first. The lab or planning prints the sheet, it gets worked through at the scale, and someone copies consumption into a second list. The end of the shift lands on a third sheet, often with figures rounded or verbally corrected along the way. The next morning three sheets do not match, and none of them is even wrong on its own.

A continuous data model connects recipe, batch, consumption and close. The sheet is then the order, the batch log the execution and the daily log the state in the evening. The same recipe version appears everywhere. If it changes, that applies to new batches and not to those already weighed. Shift handover then no longer has to run through copies and side calculations.

The interface can stay lean. At the workplace you need the next batch, the oxide and redox position, and in the evening a handover without an extra sheet. The connection has to be in the data, though. New screens on separate data stores look tidier and do not solve the problem.

The model is easy to test: can the next shift explain the day without calling the previous one? If that still takes a notebook of side calculations, the chain is not closed.

For the architecture this means drawing a melter's working day first, not the application's sitemap. Which figure is needed at six, which after weighing, which at the end of the shift? The screens follow from that. The other way round you get handsome forms and the same handover as on paper.