Splitting revocation into three claims with different sources of evidence is a useful way to think about it. The ledger saying compensation ran is the easiest one to prove, which is exactly why it gets mistaken for the whole answer.
The point about the boolean is the one I would show to product teams. If false means not proven rather than not revoked, the UI has to say so, otherwise a green badge turns an external timeout into a claim of completion.
I also agree that both collapses are wrong. Reading unknown as not revoked leads to a second revocation, and in payment or messaging systems that can be as harmful as missing the first one.
At Ascendra Ventures we write states like this into the acceptance checks when we build agent features, because "done" for a side effect needs evidence from the system that owns it. How do you surface the disputed state to the person who triggered the original action?
Not to the person who triggered it, yet. That is the honest answer.
The disputed state is computed as a relation between what the revoke claimed and what the target gave back, so we put it where the two sets are kept: the operations view marks the group, stores the rejected claim and the diff, and a bulk revoke result carries disputed so a summary cannot read as all green. The personal Action Center, which is what the person who started the call sees, projects status, revoke class and the target's current state. It does not carry the dispute. They see "revoked" or "unknown", but not "the two sides disagreed".
The part I do not want to hand-wave: the operator needs the diff, the triggerer needs a different sentence. Something like "this undo is not confirmed, here is what is still holding and who owns it", with the evidence one level down. We have not written that projection. Your acceptance-check point is the same standard applied one step earlier; we apply it to the operator today and not to the person who started the call.
Splitting revocation into three claims with different sources of evidence is a useful way to think about it. The ledger saying compensation ran is the easiest one to prove, which is exactly why it gets mistaken for the whole answer.
The point about the boolean is the one I would show to product teams. If false means not proven rather than not revoked, the UI has to say so, otherwise a green badge turns an external timeout into a claim of completion.
I also agree that both collapses are wrong. Reading unknown as not revoked leads to a second revocation, and in payment or messaging systems that can be as harmful as missing the first one.
At Ascendra Ventures we write states like this into the acceptance checks when we build agent features, because "done" for a side effect needs evidence from the system that owns it. How do you surface the disputed state to the person who triggered the original action?