Before you press replay, list what will run again

Write the replay boundary down before running the test. Which state is restored? Which calls execute again? Which results come from history? Those answers determine what the result can establish.

Why does “replay” need a definition?

LangGraph’s time-travel documentation says replay resumes from a saved checkpoint. Nodes before that checkpoint do not rerun; nodes after it do. Those later nodes can issue LLM calls and API requests again, and their results may differ. LangGraph documentation.

In the documentation’s example, replaying just before write_joke runs that node again but preserves the earlier generate_topic result. This is a concrete execution boundary, not a blanket claim that all answers are reproducible. Example.

What does workflow history tell you?

Temporal’s overview describes checking generated Commands against a Workflow Execution’s existing Event History during replay. It also describes Activities as the way Workflows interact with their environment. These concepts help explain recovery, but our retrieved passage ends before the full replay discussion. We therefore do not infer its detailed Activity-output behavior from that excerpt alone. Temporal overview.

What should an evaluation record?

Our take: identify the checkpoint or history, the code being executed, the inputs reused, and the model or external calls made again. Report fresh execution separately from reconstruction of recorded state. A useful comparison needs those boundaries before its “same result” claim can be interpreted.

This is a technical briefing based on documentation reviewed October 11, 2026, not a new product release or an independent runtime comparison. Neither retrieved source displayed a publication date.

Use the Deterministic AI Checklist and testing protocol to specify the evidence you need.