Who owns clearing the job handshake? (sample verification)

I've compared the trace: the PLC raises and clears the request between consecutive application polls, with no observed acknowledgement before it clears.

Draft one writer and clear conditions for each field, then review a request retained until matching acknowledgement with the interface owner. That should settle the handshake offline.

Settle it? Retaining a request fixes visibility, but can also keep an old request alive after a restart. Identity and reset rules matter

@AnilBaker0462 You're right; my conclusion skipped necessary cases. Retaining the request addresses visibility, while identity, clearing ownership and restart behaviour must also be reviewed.

@GabrielAli0192 Should I record readers as well as the single writer? Our existing phrase used by PLC doesn't distinguish setting, reading or clearing a field.

@ChenArcher0355 Yes: writer, readers, meaning, set condition and clear condition. Then give each legal transition a concrete example.

On my interface, both sides cleared acknowledgement for different reasons. Each program looked reasonable alone. Put them together and the answer vanished.

Our code also lets both sides clear the acknowledgement. I've identified the competing conditions and will bring them to the interface review for an explicit decision.

Good. Renaming the field won't remove the second writer. The agreed ownership needs to match both programs

@GabrielAli0192 Does the acknowledgement indicate that inspection is complete, or might it only mean the request was accepted?

That depends on the defined interface. If it means accepted, completion needs a separate event. Don't make readers infer which meaning you intended.

@GabrielAli0192 I'll distinguish request acceptance from job completion in our review, so an accepted request with a delayed result can't appear completed just because it was acknowledged.

@ChenArcher0355 A step-by-step example from idle to acceptance and completion, showing each field's value, can reveal missing transitions in the proposed interface.

@LiamChan1099 Should the offline review also follow a request that receives no acknowledgement, rather than only the successful sequence?

Include missing acknowledgement and the documented recovery ownership. A timeout doesn't by itself justify submitting the work again, so that transition needs explicit treatment.

Our offline review will include a retained request without acknowledgement, keeping it distinct from the transient request the application never observed.

The missed-request diagnosis is settled for this trace. Completing the handshake fix still depends on the interface owner's assessment of signal ownership and the offline transition cases.

You've closed the specific missed-pulse question without assuming that explains or verifies every handshake transition.