The machine supplier's ready means it received the request; our integrator's ready means the loading area is available. Both sound reasonable until we try to write the FR10 spacer sequence. How do I get a shared state table that tells the next shift what those moments actually permit?
Put a request arriving while the machine is occupied into the table and ask each author to describe what changes then, because that is where their shared word stops describing a shared condition; labels can follow once receipt and availability have separate meanings.
Include who produces each indication, what keeps it valid, and how it is withdrawn. The table needs to describe the ordinary interface behaviour as a sequence, not just rename one disputed signal into two equally vague signals.
Leo, the machine team can acknowledge while still occupied; the integrator had assumed that acknowledgement meant available. Grace and Leah, neither copy defines withdrawal yet. Dean, our controls lead will own the shared revision, with both supplier authors approving their entries.
Does the wording distinguish ordinary waiting from a condition that needs an authorised person to investigate, rather than merely display a different technical label?
Darcy's distinction is worth trying with a reader, once the design meaning exists. I've seen a correct setup selection conceal an incorrect physical arrangement in a teaching exercise; a confident answer to what did you choose isn't the same as what does the system know.
Nora, both accepted it in the shared table. Luis and Darcy, the proposed screen says request received, waiting for loading availability in that case. Unavailable and unexplained mismatch are not being treated as interchangeable messages, though the recovery responses are still being designed.
Include the person covering a break in the reading check. A regular operator can supply missing context from habit, while the cover operator gets blamed for asking the question the handover omitted.
I would review withdrawal and restart with the attempt context visible. The ordinary request exchange must not accidentally carry an old acknowledgement into a new loading request just because the connection or application restarted.
Grace, agreed, and don't ask the operator to reconstruct that context from memory if the interface loses it; the uncertain case needs an explicit design response, not a reassuring phrase on the training slide.
Leah, the authors now define availability as a current condition that can be withdrawn; the integrator must re-evaluate it under the agreed sequence, not latch the earlier receipt as permission. Grace, restart with an unresolved request remains a separate open design row.
That gives the reader check something concrete: what is known to be received, what is currently available, and what remains unresolved after interruption.
Our regular operator and break-cover colleague read the draft. Both understood the normal waiting case, but the cover colleague thought the restart row allowed sending a fresh request. It doesn't. We've returned that row to the authors with the misunderstanding attached.
Useful catch. Fix the design explanation and permitted response before teaching a preferred answer; the reader exposed an ambiguity, not a lack of willingness.
The controls lead and nominated maintenance cover own that escalation in the draft. Receipt and availability definitions are agreed, but the restart row needs its final design review and another reader check before we issue the handover or implement the exchange.