It is nine in the morning and the laptop's lane says the search-shortcut work is running. That is true in one sense: running is the last thing the machine recorded. It is also possible that the machine stopped at two in the morning and has not said anything since.
Those are two different questions, and a status view that answers only the first is the one that eventually lies to you. So ROOK keeps them apart: what was last recorded, and whether that record is still recent enough to be evidence.
Live, stale, draining, stopped
While the loop is running, the machine re-records a short marker for itself about once a minute. A beat is an ordinary recorded event, so a machine that cannot write to its record cannot beat either, which is what makes the beat mean anything at all. The view treats the newest evidence as fresh for a few missed beats, then stops treating it as fresh.
| Lane reads | What it means |
|---|---|
| Live | A recent beat, and the last recorded state says work is running. |
| Stale | The beats stopped. The last recorded state is shown with the time it was last heard from, not as a current fact. |
| Draining | You asked it to wind down. No new work starts; work in flight is finishing. |
| Stopped | The machine recorded that it stopped. This is a fact it wrote, not something inferred from silence. |
The distinction between stale and stopped is the one that matters when you are away from the desk. Stopped means I stopped it. Stale means it stopped answering. Collapsing the two would take the one question you actually have from a phone and give it the same colour as a routine shutdown.
A closed laptop reads stale, which is correct: nothing was being supervised while the lid was down. Opening it again resumes the beats and the lane returns to live on its own. There is no sleeping state, because a sleeping state would be a claim the record does not hold.
Doing this without a status view
By hand, you would check the terminal that was doing the work. If a session is scrolling, it is alive; if it stopped hours ago, you see that too, in the same window.
That check is real evidence, and it is completely sufficient while you are sitting in front of the machine. Its weakness is that it does not travel. Move to a phone and the thing you were reading was never a status, it was output, and the substitute people reach for is a dashboard that shows the last thing it heard. That substitute is exactly the failure above: an unattended machine that died in the night still reads green at breakfast. What ROOK adds is not a prettier light. It is the second signal that lets the light go honest-down when contact is lost.
Three controls, three reaches
Pausing new work, draining a device and stopping everything are different actions, and the difference shows up in what happens to work that is already in flight.
- Pause new work — nothing new is picked up. Whatever is running continues.
- Drain — no new work starts and the current unit runs to its next recorded boundary, so it stops somewhere a later session can resume from. If draining takes too long, it becomes a safe hard stop rather than hanging forever.
- Stop all — the broad boundary, across the fleet, when you want everything to end now.
Keeping them separate is what prevents a quiet pause from being read as an immediate stop. If you tap pause and walk away, work you can see in the pane is still finishing, and that is the intended behavior.
Limits
The lane is derived from the last recorded status and the freshness of that record. Delayed writes, a lost connection or a failure on the origin device can all put it behind the machine's real state. The design is to make that uncertainty visible and to say when the device was last heard from. It is not a promise that the lane is never wrong, and a live lane is not proof that every process inside the machine is healthy.
Next
You have seen the whole system on real machines. The last question is the one a reader arrives with: what actually exists today, and what can you trust it with? Continue to status and limits.