Our inspection page says no job after the PLC's short request expires, even when the application missed it. The operator takes that as permission to press again. I want both interface owners to agree what request, acceptance and no answer mean before I write another paragraph of instructions that contradicts the screen.
We found tutors read waiting in two different ways, so I would show them the proposed states on paper as well as agreeing the signals. Who sets and clears the request, and what does the application retain if it restarts? Those answers need to support the words.
PLC is the only request writer but clears on a timer. The proposed version holds it for matching acceptance. App currently forgets the attempt on restart, so that's another change, not something a better waiting label can solve.
Exactly. Keep the delayed-answer and restart cases in the review, with the tutor seeing the proposed recovery too. Thanks for naming the app's lost identity; I would rather teach an explicit unresolved case than let a blank page invite another request.