Related, yes, although the current prototype is narrower. Chandy-Lamport captures a consistent global state across communicating processes whereas TCC checkpoints program continuations at compiler-defined durable boundaries.

Yup, essentially capture state now so execution can continue from it later. The difference is that this checkpoint represents compiler-known program state (live values and control position) rather than an entire process or address space. That lets it omit dead state and the completed execution prefix.

BTW, for some reason a lot of your comments are dead. I'm bring them back.

Which rough edges pushed you toward the same mechanism - history growth, replay latency, determinism/versioning, worker ops, or the programming model? Happy to compare notes.

Yes, Monty is highly relevant. Its ability to serialize and resume a paused interpreter has a clear relationship to this work. I would say the main difference is scope; Monty is a secure Python interpreter for AI-written code, while TCC is exploring durable execution semantics around effects, waits, child executions, and persisted continuations, eventually across language frontends. Thanks for the insight, I'll definitely add Monty to the related-work discussion.

Well checkpointing does not make an incorrect program correct. Durability just guarantees that execution can survive infrastructure failure, not that the resumed program will not encounter the same deterministic bug again.

TCC checkpoints at explicit durable boundaries rather than at an arbitrary instruction immediately before a crash. So if the next operation repeatedly fails, ordinary retry limits or operator intervention are still required.

My proposed model is to represent the recoverable program state as a committed continuation, rather than reconstructing state by replaying the completed execution history.

Fair point. The paper explains the execution model and evaluation, but I should have included a concrete source-to-continuation transformation. I kept the implementation discussion too abstract while the design was still evolving.

Essentially, the compiler lowers the program into an explicit state machine, and a committed checkpoint contains the next state identifier along with live values and any relevant control states needed to resume execution. For recovery, a fresh runtime hydrates that frame and resumes directly from the saved state rather than replaying the completed history.

Closer to compiler-generated continuation checkpointing than event sourcing.

In the current prototype, the compiler lowers the program into an explicit state machine, and then at each durable boundary - waits, external effects, child executions, etc - it commits the next program position along with live locals, control state, and any values needed to continue execution.

When the program crashes or is killed while executing, a fresh runtime loads the checkpoint, reconstructs the frame, and dispatches directly to the saved position - no history replay.

External effects still have the usual ambiguity window: an operation may succeed externally, but the process may crash before its result and the updated checkpoint are durably committed. To solve this, TCC gives each effect a stable identity, but non-idempotent operations still require provider-supported idempotency or reconciliation. Otherwise, recovery from the last committed checkpoint may attempt that individual effect again.

TCC addresses continuation recovery, not the exactly-once external I/O problem.