From the batch ticket through the batch book to the daily log

The batch ticket says what should go into the furnace: which recipe version, which target weight, which redox state. The daily log says what the day made of it: which batches ran, what the shift leaves the next, whether the day is closed. On paper these are two worlds. In software they must not stay that way.

The fracture looks harmless. Lab or planning prints the ticket. The scale works it off. Someone copies consumption into a second list. End of shift is recorded on a third sheet, often with figures rounded or corrected by mouth along the way. The next morning three sheets disagree, and nobody is wrong inside their own system. They simply do not share one.

A continuous model connects recipe, batch, consumption and close. Not because integration is fashionable, but because otherwise the handover happens again in copies and side calculations. The ticket is then the order, the batch book the execution, the log the state in the evening. The same recipe version stands at all three points. If the version changes, that applies to new batches, not to those already weighed.

The interface can stay lean. A melter does not need an architecture diagram. He needs the next batch, the oxide and redox position, and in the evening a handover that does not need an extra sheet. The connection still must not live only in the interface. Screens alone, with the data kept apart, ship the fracture with them. It only looks tidier.

A test for the model: can the next shift explain the day without calling the previous one. If a side calculation in a notebook is still required, the chain is not closed. If the close can produce the same day again tomorrow, it is closer.

Takeaway for architecture: draw a melter’s day first, not the application sitemap. Which figure 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.