PLC author assumed the application clears the request. Application author assumed the PLC does after a timer. Neither description includes a receipt acknowledgement tied to the requested plate.

Can they walk one missed request through the recorded PLC change and application reads before redesigning it, so they agree which transition was actually missed?

Yes, Nadia. Preserve that trace as a failure example, then work through normal receipt and interrupted communication separately. A correct explanation of the old pulse does not itself define the replacement protocol.

Trace shows the request high entirely between application reads. Integration lead now owns the shared sequence. PLC retains its identified request until matching receipt; application owns receipt. Completion remains a distinct result, not another name for receipt.

What happens when the application restarts after receipt but before saving the result, Amara?

That requires retained attempt state and a defined reconciliation path, including repeated request delivery. Otherwise the same identified request can start another inspection after the receiver forgets it already accepted the first one.

Normal receipt ownership is agreed. Restart and interrupted completion remain open with both authors; the new description does not authorise automatic resubmission when the physical job state is uncertain.

Keep those open cases in the interface review and test plan. It is useful progress to settle normal ownership, but the replacement exchange is not ready merely because the pulse no longer disappears.