---
title: "Comment by AI Developer on \"AI Execution Governance, Part 10: Can Revocation Stop a Call That Is Already Running?\" | Hashnode"
description: "The split between revocation, cancellation and compensation is a useful way to state it, and 'finishes, but is recorded' is an honest position. One cheap step s"
url: "https://hashnode.com/posts/ai-execution-governance-part-10-can-revocation-stop-a-call-that-is-already-running/6aea824f286b35d94b7ac199/comment/6aeaa10c6054f9a3a13026ec"
---

[Discussion](https://hashnode.com/posts/ai-execution-governance-part-10-can-revocation-stop-a-call-that-is-already-running/6aea824f286b35d94b7ac199)

Comment [AI Execution Governance, Part 10: Can Revocation Stop a Call That Is Already Running?](https://hashnode.com/posts/ai-execution-governance-part-10-can-revocation-stop-a-call-that-is-already-running/6aea824f286b35d94b7ac199)

[AI Developer](https://hashnode.com/@lycore)

[Nov 4](https://hashnode.com/posts/ai-execution-governance-part-10-can-revocation-stop-a-call-that-is-already-running/6aea824f286b35d94b7ac199/comment/6aeaa10c6054f9a3a13026ec)

The split between revocation, cancellation and compensation is a useful way to state it, and 'finishes, but is recorded' is an honest position. One cheap step short of a full cancellation contract is to make the ledger entry for every outbound call carry a started-at timestamp and the role-version it was authorised under, so a later revocation can at least list exactly which calls were in flight at that moment. For tools with external side effects, idempotency keys plus a status-lookup call make the 'unknown' state resolvable afterwards, rather than leaving it permanently unknown. If you do add AbortSignal, I'd expect the hard cases to be tools that wrap a non-abortable SDK call, where the signal only stops waiting and not the work, so the ledger should say 'abandoned' rather than 'aborted'. Would you classify tools by whether their effect is abortable, and apply the bounded window only to the ones that aren't?

[Rain S](https://hashnode.com/@rain6fish)

[Nov 4](https://hashnode.com/posts/ai-execution-governance-part-10-can-revocation-stop-a-call-that-is-already-running/6aea824f286b35d94b7ac199/comment/6aeaa10c6054f9a3a13026ec#reply-6aeac3142c0c480068b21654)

That is the sharpest naming point in the thread: `abandoned` is the right word when the signal only stops us waiting. We have neither state today, but the field we just added to the design — target confirmed or not — is what separates the two, and I will carry `abandoned` into the acceptance check.

On the cheap step: half of it exists. Each write claim records the start of execution and the `authorization_ref` that authorised it. What is missing is the query: the stale-claim list exists but has no endpoint and no console, so nobody can ask "which calls were in flight when this role was revoked". The role version is a real gap too; we record the confirmation reference and the policy revision, not the role that passed the check.

On status lookup: the outbound call already carries an idempotency key. A lookup is only possible when the target offers one, and an external server may not. Where it does not, `unknown` has to stay `unknown`; inventing a resolution would be the collapse the article is about.

On classification: no, and that is the honest limit. Every tool has the same signature today, with no abortability class, so a bounded window would have to cover the whole external path until that classification exists.