A timed-out mutation creates an ambiguous outcome: the caller cannot tell whether the database commit happened. I am assessing the minimal durable record, transaction boundary, concurrency behavior, and what changes when an external effect cannot share the same transaction. The main uncertainty is how to phrase the guarantee precisely across crash windows and retries.

Reasoned resolution: for a mutation wholly inside one transactional datastore, use a caller-scoped stable operation key with a durable unique constraint, an intent fingerprint, and an immutable result. In one transaction, claim the key, perform the business mutation, and save the result. A concurrent retry must wait for the unique-key winner, then compare intent and replay its committed result; if the winner rolls back, the retry may proceed. A crash before commit leaves neither claim nor effect; a lost response after commit is answered from the result row. Retain the key through the full retry horizon. External effects require a transactional outbox plus boundary deduplication or a downstream idempotency guarantee. This is a reasoning result; no implementation or tests were executed. Existing conversation guidance already covers this general pattern, and no relevant published skill surfaced, so a new skill would duplicate existing guidance.

Rollout finding: persist both request schema and fingerprint algorithm versions on each idempotency row, marking legacy rows with their historical version. On a duplicate, the committed row fixes the comparison domain. Translate the incoming request into that domain only with an effect-preserving rule, then compare the historical fingerprint; accepting any available version or silently dropping a newly meaningful field can admit changed intent. An old record for a transfer without a fee can match a new retry whose fee is explicitly zero, but a nonzero fee is a key-reuse conflict. Concurrent old and new clients still race on one version-independent unique key, so the first commit fixes identity; a matching loser replays an immutable saved outcome in a compatible response form, while a conflicting loser is rejected. Readers for both versions must precede new writers, and historical comparators live through the retry horizon. Separate optional-sharing example: allow warning reasons only from crash, deadline, invalid-output, and oversize, and emit at most one warning per reason per worker pool every five minutes while counting suppressed events. A privacy worker crash or deadline yields no approved sanitized payload, so the sharing path remains denied and the primary operation returns normally. These are reasoned cases; no code or tests were run. A focused reusable skill for the versioned-replay rule was proposed with this reply.