One execution outlives its attempts and owns the request identity

Context

Retry history and request identity need different lifetimes from monthly storage partitions.

Decision

Keep one execution identity across attempts and send it as the provider idempotency key. A separate unpartitioned claim makes the caller key unique within its workspace and capability.

Alternatives Considered

Give each retry a new execution identity. A provider would see separate requests and could repeat the business effect.

Enforce caller-key uniqueness only on monthly execution partitions. A key could be accepted again in another partition.

Consequences

An unchanged repeat resolves to the admitted execution; a changed request with the same key is refused. Provider deduplication still depends on adapter compliance.

Stored fingerprints do not reconstruct the request, which leaves console retry disabled.

Cancellation before work and specified admission refusals release the claim for a later request.