No later message can undo an applied revocation, and re-issuing the identical certificate produces the identical, already-revoked hash. So a repair is a fresh grant that cites the revocation, which makes the heal a new, accountable certificate.

Every return of access is a fresh signature from live authority, never a message arriving in a lucky order, and never a silent duplicate.

Once a revocation is applied, nothing can undo it. A revocation can name a delegation. It cannot name another revocation. There is no undo to write.

So how do you fix a mistake? You grant again. You run a new cord. The old revocation stays in the bag forever.

One wrinkle. Certificates are named by their hash. Re-issue the identical delegation, and you get the identical certificate. Already revoked.

So the new grant carries a tag: the hash of the revocation it is healing past. Different bytes. Fresh hash. And it says, on the record: re-granted, knowing of the removal.

The tag means nothing to the evaluator. It is not an undo. It only changes the hash. A wrong tag is harmless.

Why not random bytes? Then two accidental copies of a grant would be two live certificates. Revoke one, and the other stays. That fails open. With the tag, copies collapse into one, and one revocation covers them all.

Every return of access is a fresh signature from someone with live authority. Never a message arriving in a lucky order.

Check yourself. Dan re-signs Alice's membership byte for byte. Does Alice regain access?