our fr10 incident export loses the one identifier I need

Yes, in the raw request record. I don't yet know its lifetime or whether it starts again after controller restart. Application restart definitely happened; controller restart isn't established.

Can the package author explain the field's scope and link both records within their source session? A matching number is useful only if it identifies the same exchange rather than being reused in another session.

Retain the raw files before fixing the export.

And give the bracket an explicit unresolved status while you investigate. We had a lovely incident timeline once, but the person at the bench only saw the last green result. The physical item and the software investigation need to stay connected.

Raw files retained, Imran. Bracket is held by quality, Fiona. Author confirms the field is scoped to the recorded controller session and is comparing the two request records with the acknowledgement.

Is the session identity retained too?

It is. Same controller session across these records. Author matched the acknowledgement to the earlier request; later attempt has another sequence value. That link doesn't use the wall-clock ordering.

What does the matched acknowledgement mean in that package: request received or inspection completed? Recovering ownership still leaves the event's meaning to establish.

Receipt only. Our export labelled it complete, which is a second mistake. No inspection result recovered from that event, and quality's hold stays put.

Good catch. Fix both omissions in the export.

Please keep the receipt-versus-result example in the teaching notes too. Otherwise the next person can follow the identifiers perfectly and still tell the operator that a bracket passed when all they found was a received request.

Will the revised recorder include application attempt identity as well as the controller's scoped exchange reference? That should let the maintainer follow the relationship without reconstructing it from raw files every time.

Yes. Revised export preserves both references, source session and actual event meaning. Controlled replay of the two requests, restart and delayed receipt now shows the earlier request received and the later one still without receipt.

Does the display still call the old receipt complete?

No. Display corrected alongside export. Maintainer reproduced the captured sequence through the normal reporting path; both agree. Quality has since issued the bracket's disposition from its own review, not from this receipt.

Thanks for returning with the event meaning as well as the matching number. That's a useful resolved investigation: you found which request received an answer without turning that answer into an inspection result.