---
id: INT-14
family: RT-INT
level: core
profiles: [runtime]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-int/int-14
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# INT-14 — A terminal snapshot is not resumable

*RT-INT (Part II) · level: core · profiles: runtime · added in 1.0*

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

> **Normative.** This is the rule.
>
> 1. A snapshot whose status is terminal (completed, failed or cancelled) must not be resumed.
>
> 2. 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.
>
> 3. 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.

```json title="That checkpoint, explicitly resumed as a run" verdict="refused"
{"status": "completed"}
```

```json title="The same checkpoint, restored to seed a new turn" verdict="continued"
{"status": "completed"}
```

## Why

Recorded under OPEN-10.

## Related rules

- Names: INT-13, INT-15
- Referenced by: INT-8, INT-13, INT-15

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.