A checkpoint round-trip preserves cancellation
Whether a run was cancelled or completed cannot be re-derived after the fact; "finished" looks identical either way. So the outcome is recorded, not inferred.
The rule
- Execution state carries its terminal outcome explicitly (completed, failed or cancelled, and unset while the run is live), and a checkpoint persists it.
- A snapshot's status is the persisted outcome, never a re-derivation from whether the run finished, which cannot express cancellation.
- A cancel signal marks the state cancelled and writes the final checkpoint.
- Seeding a new turn from a terminal state clears the run state, outcome and execution position alike (SG-12), so a recorded cancellation never closes a conversation thread; only explicit resumption of a run is gated (INT-14).
What it means
"Finished" looks the same whether a run completed, failed or was cancelled, if all that is stored is whether it finished at all. Deriving the outcome from completion alone cannot tell a deliberate cancellation apart from an ordinary finish, so the outcome has to be written down as its own fact, and a checkpoint has to carry that fact forward rather than reconstructing it.
Cancellation recorded this way still does not close a conversation thread: seeding a new turn from a terminal state clears the run's outcome along with its execution position, so the next turn starts clean. Only resuming the run itself is gated (INT-14); continuing the conversation is not.
Example
{"isComplete": true, "error": null, "status": "cancelled"}