To answer the closing question directly: anything that mutates DNS or auth configuration, because unlike your refund example there is often no compensating action, only manual recovery. On the mechanics, the unknown state you describe, where "Marking that action as failed and retrying it may issue a second refund", is usually closed by generating an idempotency key before the call and passing it to the payment provider, so the ambiguous retry becomes safe by construction; the receipt then stores the key, which also gives you the join between attempts. One property the schema still lacks for the compliance use case: tamper evidence. If receipts are ordinary mutable rows, an incident review cannot prove the record was not edited after the fact, so an append-only store or hash-chaining each receipt to the previous one is what turns this from good logging into audit evidence. Is that a direction you are taking this?