State File as Sole Continuity

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A catalog migration spans sessions, risking repeated work or stale results after compaction. The teaching plan is v2, IDs 10 and 11 are finished, and 12 is next. Store artifacts and check records in this plan’s progress.json rather than borrowing another task’s ledger.

Mechanism

After each batch record plan identity, input revision, completed IDs, artifact paths/hashes, check commands/results and the next item. Distinguish in-progress, edited and verified rather than hiding missing checks behind completed. On resume, verify the correct ledger, current inputs and artifacts before skipping work. Recheck affected mismatches. Save via a temporary file and replacement to avoid half-written JSON.

Bad example

Remember completed catalog items in conversation. After compaction, rely on recollection; redo everything if unsure or reuse any progress.json you find.

Good example

Update plan v2's own progress.json with artifact paths, actual SHA-256 values, edit status and check commands/results for IDs 10 and 11; next is 12. Mark unverified items explicitly. On resume check plan identity and input revision, then recompute hashes. Skip work only when evidence matches and checks remain applicable. Recheck affected differences. Save through temporary-file replacement, not inferred conversation memory.

Why the change matters

Conversation memory is unstable, and a file without task identity or artifact checks can also be stale. A versioned ledger binds progress to inspectable objects, avoiding repetition without treating recorded success as timeless truth.

Observable expectation

Resume the teaching ledger at ID 12. Changing ID 11’s artifact should invalidate its hash and require inspection, not leave it skipped. A ledger for a different plan should not be reused.

Verify recognizable unverified states, parseable files and claims tied to current artifacts. The fixture does not invent hashes as if actual verification had occurred.

Limits

A ledger is an evidence entry point, not authorization or infallible truth. Changed inputs/shared code can invalidate old checks, and equal hashes establish byte identity only. Multiple writers also need ownership or locking; temporary replacement alone does not resolve all concurrency conflicts.