Restarting a kernel removes variables without undoing work already performed elsewhere. An empty result list in memory must not cause the whole batch to run again. I put continuation evidence in the host's file journal rather than relying only on Python variables, separating reopening the work from executing it another time.

Place the journal outside the kernel-owned result list

A Workflow instance keeps current results in memory, but operations-mode status asks the host for program status. The host locates a file under the program using context key and job identity. Reconstructing a Python list and reading a retained business journal are different paths.

The library single-run mode can report its own in-memory results instead, so it must not be described as providing the same persistence. File-backed continuation belongs to the project operations route. The adapter retaining evidence matters more to a recovery explanation than the general statement that the tool uses notebooks.

Distinguish a missing file from an unreadable record

A missing journal starts an empty item list for new work. An unreadable document or other load error becomes an invalid-record failure. Corruption is not silently converted into an empty batch that appears never to have run. Absence and failed interpretation carry different operational meanings.

The original function is not a complete schema validator for every retained field. This article does not add that broader guarantee. The independent module applies stricter identity and field checks to its narrower synthetic format. Product behavior and explanatory additions remain distinguishable rather than being merged into one claimed implementation.

Intent records remain useful before final results exist

The host saves a running item before requesting execution, then attaches run identity, completed steps, output location and error when work returns. Even without the final write, an earlier trace can identify the intended item. That trace must not be promoted to success.

A retained running value does not prove a process is still alive. A missing process also does not prove no external action happened. Recovery examines those separate uncertainties. Loading the journal does not automatically reconcile the original service outcome; it preserves information needed to ask that question accurately.

The retained scope includes program, project and job

Equal job identities under different context keys locate different files, and the program location is also part of the boundary. Empty memory in another project cannot justify borrowing completion from the original project. The operator needs the intended project and program before continuing.

A recreated kernel connection is no reason to redefine that scope. A copied project, however, may represent new work. Instructions to retain identifiers must coexist with instructions against mixing owners. Having a saved file is not sufficient evidence that the correct file was read; the retained scope must match the intended work.

Recreate the service when checking persistence

The existing test completes an item through one service and requests it through a newly created NotebookPrograms instance. It checks reuse and execution count, then reads retained history and the output directory. Continuation is not inferred solely from repeatedly querying the same memory object.

That tests host-service recreation and files, not every actual Jupyter shutdown condition. This content work shuts down no original kernel. The independent module reopens its file journal and injects save failures in twenty-four tests. File persistence and full kernel recovery retain separate verification scopes throughout the explanation.

Restart by reading retained facts before creating new work

An empty screen or missing variable can feel like a clean beginning, while the business operation outlives the kernel. Reading prior item state and actual execution records gives a stronger starting point than relying on the operator's memory of what happened.

Moving to another computer needs more than possession of a file: definition, SDK, accounts, selected materials and storage ownership also need checking. This implementation does not complete the separately deferred external-computer connector. Accurate recovery scope helps distinguish a fresh start from continuation of an existing occurrence.