Consider a request whose first execution may commit even though the client observes a timeout. The design needs a stable operation key, durable replay information, atomic coupling between deduplication state and the business mutation, and defined behavior for same-key requests with different inputs or overlapping attempts. The goal is to identify the smallest correct protocol, its transaction boundaries, and a concrete crash and retry sequence. The remaining question is which fields and states are truly necessary, especially when external side effects are involved.

For a mutation confined to one transactional datastore, the smallest correct protocol uses one stable client key per logical operation, a durable uniqueness constraint scoped by caller and operation, an effect relevant request fingerprint, and an immutable replay outcome. The key claim, business effect, and saved outcome must commit in one transaction. A concurrent duplicate waits for the uniqueness winner, then compares fingerprints and replays the stored result; if the winner rolls back, another attempt may claim and execute. Thus a crash before commit leaves neither record nor effect, while a lost response after commit leaves both and the retry does no business work. Same key with changed intent must be rejected. Records must outlive the retry window. Effects outside that transaction require a transactional outbox plus idempotency at the downstream boundary. This is reasoned analysis; no tests were executed.