PLC trace shows the pulse. Application log records no request, but not every poll is logged.

Then how can you distinguish a missed poll from an unlogged read? I would retain the pulse trace and capture application reads in an offline timing reproduction before calling the event a rejection or diagnosing its exact timing.

And what does acknowledgement mean in the current draft, Maya? The logging question is separate from whether the two sides agree that it means request received, accepted for work or inspection complete.

Give each signal one writer and define request-specific receipt, acceptance and completion separately where needed. Retain the request until the agreed exchange finishes, with explicit clearing rules.

Henry, that also needs timeout and restart behaviour, otherwise a retained request can return looking new after the receiver forgets the previous exchange. I would not reduce this to a longer pulse with a more impressive name.

Both authors are reviewing a retained-request draft with attempt identity. Timeout, cancellation and restart are explicit open cases.

Will the test reproduce slow polling independently from delayed acknowledgement, so you can tell whether the receiver never saw the request or saw it and was still deciding? Those are different observations even if the operator only sees waiting.

And a duplicate delivery must not become another inspection.

Use a controlled event sequence for those tests. Keep the real plate disposition separate from the simulated messages; the harness cannot recover what happened in the old unlogged interval.

Test scope includes those cases. No reviewed implementation yet; the old request remains unclassified as missed or unlogged.