@HassanBrown0878 Our trace shows it rising and falling between two polls. The PLC clears it without an observed acknowledgement. No wonder the application misses it.

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.

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

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

@HassanBrown0878 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.

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

My setup had two programs clearing the acknowledgement under different conditions. Reviewing them together exposed a conflict that wasn't apparent from either program in isolation.

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.

Make sure the ownership decision is reflected in both programs; a clearer table or field name alone won't eliminate the conflicting assignment.

@HassanBrown0878 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.

@HassanBrown0878 Our review will distinguish accepted from completed. I want a delayed result to look delayed, not mysteriously finished because a request was seen.

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

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

@JoBrown0940 Yes. Show timeout as an unresolved exchange, with the defined owner responsible for recovery. Don't turn absence of acknowledgement into an automatic resend rule.

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

@NinaBennett0762 What if acknowledgement belongs to an older request? Holding bits longer won't answer that.

@HassanBarnes0530 Add it as a mismatched-identity case. The interface owner needs to define how the supported exchange links a response to its request.

@HassanBrown0878 The missed pulse is explained, and I've got an ownership review to work from. Our complete handshake behaviour is still open.