The application keeps a job label. The retained signal has no attempt identity attached. The label can be reused, which makes matching it by name doubtful

Then don't manufacture an attempt match from the label

Are there earlier event records that identify the particular exchange? I mean evidence of this attempt, not just another timestamp close to the reconnect.

There is an application log, but the entry only repeats the reusable job label. We haven't found a unique match. The draft report now holds that result as unresolved

Have the interface owners define the future identity and acknowledgement lifecycle, including restart. Separately, quality needs to decide what can be established about the actual bracket. Repairing the protocol won't retrospectively identify this old signal.

And no automatic new job just to obtain a cleaner answer

Will the offline tests include seeing the same retained result again after another reconnect? Otherwise the first hold may work and the second observation may still increment the total.

Yes. In the offline case, repeated reconnect leaves one unresolved record and does not add an acceptance or request. Quality's physical disposition remains separate and pending. No live state cleared as part of that test

Keep the unmatched historical example in the handover too. A better future interface should not make somebody think the old result has become attributable after all.