A surviving conversation about the earlier Dijiang calculation reported 364 of 864 jobs complete. The work had been divided into jobs with different inputs, but the completed-job list and raw outputs were missing. Subtraction suggested that 500 jobs remained. It could not tell me what belonged in job 365.
In the recovery audit of July 16, 2026, I excluded that progress figure from the new analysis. I retained 364/864 only as a report from the earlier conversation and started v0.4 as a new calculation. Missing values would neither be filled in by estimation nor used to choose the new settings.
What a completion count needs behind it
Resuming a calculation requires a connection between the full job list, each job’s inputs and its completed outputs. The same filename does not establish the same job if coordinates or settings have changed. For Dijiang v0.3, the exact manifest and item-level hashes needed to verify that connection could not be recovered either. A historical archive link in a conversation did not amount to a recovered archive.
For v0.4, I froze system inputs, execution settings and analysis rules separately. The files to use, jobs to run and rules for interpreting the output were fixed before target outcomes were inspected. Content hashes provided a reference for detecting later changes. This was an internally frozen prospective procedure, not an external preregistration.
A checkpoint was not enough on its own
A checkpoint saves the state reached partway through a calculation. Loading it can avoid repeating work, but only if it belongs to the current job’s inputs. The new runner allowed an interrupted job to continue only when the checkpoint matched the job specification. A missing or mismatched checkpoint meant restarting that job from the frozen input.
Completed jobs received the same treatment. A completion marker alone was insufficient: the runner checked the job identifier and specification together with the hashes of the samples collected during the calculation and the metadata describing the run. Before resuming on another computer, it also checked the runtime and whether the checkpoint could be loaded. These controls kept valid completed files from being casually replaced by a new run.
The July 16 record includes automated tests and a deliberately interrupted resume test. After loading the saved state, the resume test finished the remaining segment and retained the expected sample rows. The save-and-resume mechanism was tested before the target calculation started. Passing that test established a working execution path.
An archive outside the working environment
A separate archive of completed jobs from the new lineage followed on July 19. The archiving tool collected files whose completion records and hashes agreed without interpreting their scientific values. It retained samples and metadata needed for analysis, while leaving bulky trajectory files recording motion over time and the external runtime separate. Preserving analysis inputs and providing everything needed to resume dynamics on another computer were treated as different tasks.
The old 364 outputs had not returned. The new calculation now left inputs, outputs, completion records and archive files that could be checked against one another. The next progress report needed to lead beyond a sentence about how many jobs had finished, all the way to the files behind that number.