A terminal snapshot is not resumable
A finished run stays finished. Resuming from a snapshot of one would re-fire side-effecting nodes against a run whose outcome is already recorded and already announced.
The rule
- A snapshot whose status is terminal (completed, failed or cancelled) must not be resumed.
- An engine offered one refuses before creating a run, naming the snapshot and its status; the same refusal covers explicit resumption from a checkpoint capturing terminal state, naming the checkpoint.
- Continuing a conversation thread is not resumption and is not gated: restoring a thread's latest state to seed a new turn carries accumulated conversation state forward and is permitted whatever the previous turn's outcome.
What it means
A finished run stays finished. Resuming it — whether from the snapshot itself or from the checkpoint that captured it — would re-fire side-effecting nodes against an outcome that is already recorded and already announced, so both paths are refused before any run or job is created, and the refusal names the snapshot or checkpoint and its status.
The clause that bites is what does not count as resuming. Restoring a thread's latest checkpoint to seed a new turn is continuing a conversation, not resuming the finished one, and it is never gated: it carries the accumulated conversation state forward whatever the previous turn's outcome was, completed or cancelled alike. The gate binds to run resume, not to thread continuity — the same checkpoint can be refused down one path and accepted down the other.
Example
A run finishes and its final checkpoint records the outcome. The same checkpoint answers two different requests differently, because the requests are different operations, not because the checkpoint changed.
{"status": "completed"}{"status": "completed"}Why
Recorded under OPEN-10.