Review what the transcript cannot prove

Pick a statement of completion

Find a transcript in which the assistant says an order was updated. Ask the team to show the operation record and target state that justify the statement. The transcript should be an explanation of those records, not their replacement.

Then remove the final assistant message from a test fixture while leaving the mutation completed. The recovery path should still know the action happened. This demonstrates that execution state does not depend on the presence of a sentence.

Repeat with an intended action in the transcript but no committed mutation. The system should not infer completion merely because the model planned it.

Trace ownership and persistence

Inspect where intent is saved, where dispatch occurs and where the result is recorded. Identify the uncertainty window between an external effect and local persistence. Ask how the system resolves it.

Review the operation identifier's scope and lifetime. It must survive retries and restarts, and conflicting payload reuse needs a defined rejection. A new identifier on each attempt undermines deduplication.

Check concurrent recovery and stale workers. The storage mechanism should enforce ownership or version conditions rather than relying on workers to behave politely after a lease expires.

Examine current authority and versioning

A resumed run should identify its workflow version and the permissions required for the next effect. Review what happens when a proposal expires, a user loses access or the target state changes.

Inspect old paused records under the new release. If their schema is incompatible, the system needs a migration, compatible executor or explicit stop state. Passing tests for fresh runs does not establish safe recovery of existing ones.

Check the saved-data policy too. Checkpoints can retain source text and tool results that need restricted access or eventual deletion.

Require a precise interruption test

Terminate a test worker after downstream commit but before local result persistence. Resume it and inspect the final target, operation count and user message. Then run the same case with two recovery workers.

Record any outcome that remains manual or uncertain and the supported procedure for resolving it. A review is useful when it exposes the exact evidence behind recovery, including what the system cannot know automatically, rather than accepting a broad promise that conversations are persisted.