
Blog · Steel Twin
Stale plant data should look stale.
A control room screen that shows old data as if it were live is worse than one that shows nothing. We think every number should carry its own age and quality, and say so.

A control room screen that shows old data as if it were live is worse than one that shows nothing. We think every number should carry its own age and quality, and say so.
Every plant has had this moment. A shift controller looks at a screen, sees a value that seems fine, and acts on it. Later it turns out the value had not updated for an hour because a connection dropped. The screen did not lie, exactly. It just showed the last number it had, in the same font and the same colour as everything else. That is how stale data does its damage: by looking exactly like fresh data.
A bakery that shows its stock on a board behind the counter has the same risk. If the board says six croissants left, but it was last updated before the morning rush, the staff promise croissants to a customer who will not get one. The fix is not a better board. It is writing the time next to the count, so anyone can see “six, as of 7 am” and know to check the tray.
In an integrated steel plant the problem is bigger, because a single view is assembled from many systems. Steel Twin joins seven: PLC, historian, MES, LIMS, ERP, EAM and energy. Each updates on its own schedule. Temperatures and flows stream continuously from Level 1. A lab result arrives when the test is done. An order changes when sales changes it. Put them on one screen without care and you get a picture that mixes the last second with the last shift, with no way to tell which is which.
The design rule in Steel Twin is that heat_id is the correlation key and every event keeps its source timestamp and quality flag, so stale data is never hidden. In practice that means a few simple things:
| Instead of | Show |
|---|---|
| The latest value, undated | The value with the time it was measured at the source |
| The time it reached the twin | The source timestamp, so delays are visible |
| A value that may be from a dropped feed | The quality flag, so a bad or stale reading stands out |
| A gap filled with the last known number | A visible gap, so nobody acts on a frozen reading |
None of this is clever. It is discipline. But it changes how people trust the screen. Once controllers know the screen will tell them when something is old, they stop double-checking everything by phone, and start trusting the parts that are fresh.
Freshness matters twice. First in the moment: holds, sequence risks and energy variances are pushed to the controller as alerts, and one tap logs the decision to the genealogy. A decision is only as good as the data it was made on, so the age of that data should be visible at the time. Second in review: every shift can be replayed with every event and its source. When a review asks “why did the controller do that?”, the replay should show what they could actually see, including which numbers were stale.
If the answer to any of these is no, fixing it is cheaper than the first wrong decision it causes. For how decisions and replays are used in reviews, see the replay-based shift review playbook, and for energy alerts by shift, steel plant energy vs norm. The full library is on the Steel Twin guides page.
Because it usually looks exactly like fresh data. A frozen value from a dropped feed can lead a controller to act on a reading that is an hour old.
Every event keeps its source timestamp and quality flag, joined on heat_id, so stale data is never hidden.
A replay should show what the controller could actually see at the time, including which numbers were stale, not what the data looks like afterwards.
See it on your own data. Steel Twin — Every heat, traced to the coil. Book a 30-minute working session with an engineer.