Two FR10 programs each expect the other to clear the request

Application calls its result response an acknowledgement. PLC author expected acknowledgement as soon as the request was received. They weren't even waiting for the same event.

Then name receipt and result separately. One word has already cost you a debugging session.

Would a simple sequence table help them compare that before implementation? Include a request that is never received, not only the complete exchange where both meanings eventually become true.

The handover also needs the application's restart after receipt. A complete request may still have an uncertain result, and the operator should not be asked to create a new inspection just because the application came back.

Will, yes, we have a table now. Dinesh, the restart case is absent from their current diagrams. I've added it as an unanswered case, not drawn my own arrows for them.

What survives restart on each side? A table with an identity column will not help if one program forgets the value at the exact point it needs it.

And is that identity an attempt, or just the bracket job name? Same family can be inspected twice.

Current app keeps only the bracket job name. PLC has an exchange counter, but the application never saves it. That's another explicit gap for the authors.

Does the counter have a defined lifetime across PLC restart too? I would ask that before making it the common identity, rather than discover later that both sides can reuse it.

Will's question is important for the maintainer. Please keep the expected behaviour for an unknown old event in the design, even if you choose a better identity for future exchanges.

PLC author confirms the present counter resets. They are defining an exchange identity with restart behaviour, rather than simply exporting that counter and calling it unique.

Include clearing an already completed exchange and receiving its result again. Those are separate cases from a new request. Otherwise a repeated event can create new work under the improved names.

A longer pulse was looking wonderfully simple before all this.

It can be part of an implementation, Imran, but it cannot answer who still owns an unreceived request. Lucy's original objection survives even if the pulse stops being missed in a demonstration.

The authors now agree separate receipt and result events, explicit ownership, and an unresolved route after uncertain restart. Clearing conditions are written for success and timeout. No code change presented as finished yet.

Who will read the proposed operator messages without either author explaining them? That was the useful last step in our handover review; the diagrams made sense sooner than the recovery wording did.

Our shift lead and a covering operator. They haven't seen this design discussion. I'll use the missed-receipt and uncertain-result cases, not just ask whether the screen looks clear.

And let them identify whom to call when the defined review cannot establish the outcome. A recovery page can be clear about the uncertainty and still leave its user stranded.

Paper walkthrough caught exactly that: no named escalation contact for unresolved outcomes. Added with the shift lead. The agreed interface is ready for implementation and testing, with the missing cases still on the test list.