Resume from a checkpoint with evidence attached

TL;DR: Resume from a durable task record containing current inputs, accepted artifacts, evidence and unresolved effects. Revalidate those facts at startup; a conversation summary is useful orientation but cannot certify that the next action is safe.

Where you are. Northstar's evidence path works within one session. You are making the coding and procurement tasks survive a fresh worker with no prior conversation.

Leave the next worker a decision, not a story

A handoff saying “nearly done, just finish the order” leaves the next worker guessing. Was the amendment approved? Was it sent? Did the service return a receipt? Which order revision was checked? Each answer changes the next permitted action.

Use a structured checkpoint for facts and a short narrative for explanation. For a coding task, record the task specification, candidate identity, verification results and next unresolved check. For procurement, record the current order revision, proposal digest, approval identity and any prepared action whose outcome remains unknown.

The checkpoint does not need to contain secrets or every retrieved document. Store controlled references that a resumed worker can resolve with current permissions. A hash or record ID can still identify sensitive customer work; it is not automatically anonymous or suitable for an external tracing service.

Select work from dependencies and current evidence

A feature ledger is useful when it distinguishes these states:

These are semantic distinctions, not a requirement to put every state in one database column. The companion separates run status, checkpoint data, verification evidence and the effect journal. A useful UI can combine them without losing the difference between a failed check and an uncertain remote write.

Choose a small ready task whose dependencies are satisfied. If the browser cannot start because its fixture is missing, editing another unrelated feature does not resolve the blocker. Record the missing prerequisite and choose another independently ready task only if that work is inside the authorized scope.

The first step is inspection. A new worker does not inherit authority merely by reading an old checkpoint. It obtains current access and ownership before executing a new operation.

Write a handoff that survives a context reset

Here is the supplied Northstar checkpoint in plain language:

• Task T-17, specification spec-3, candidate c17.
• Boundary predicate checks passed for both supplied limits.
• Browser behavior has not yet been checked.
• No deployment or customer amendment was attempted.
• Next step: start the synthetic workbench on the candidate and test the review state.

This is enough to choose the next action. It also prevents the next worker from claiming the whole application is verified. Keep the exact verifier identity and artifact digest in the structured record behind the short summary.

A clean session boundary preserves owned work, names running processes and records unresolved effects. It does not require deleting every uncommitted file. If a patch is unfinished, keep it in an identifiable workspace with an explicit status. If a local fixture server was started, stop it or transfer its ownership intentionally. Silent background processes make later observations harder to interpret.

Do this before moving on

Deliverable: write a checkpoint for an amendment where intent was persisted, the service request was sent and the response timed out. The local record contains action effect-17, order N-104, revision 7 and quantity 16. No receipt has been observed.

Worked review. Record the effect as unknown, retain the exact proposal and action identity, and make receipt lookup the next step. Do not record “failed” or generate a new action key. The checkpoint should also identify who owns reconciliation and which service idempotency contract applies.

Change the input. On resume, the service is unavailable. The effect remains unknown. The worker can report the unresolved state and stop further dependent writes; it cannot infer that the original request failed. A new conversation and a smaller context window do not change the external outcome.

For the coding checkpoint, change the candidate after the predicate checks pass. The new worker must obtain evidence for the changed artifact. The old result remains useful history, but its applicability ends at the old revision.

Go deeper

• Agent memory: Separate durable task facts from the model’s working conversation.
• Cross-session memory question: Defend write policy, scoped retrieval and invalidation across multiple sessions.
• Kill-the-worker lab: Practice resuming from persisted evidence after the running process disappears.

Key takeaways

• Checkpoint task identity, evidence and unresolved effects separately from narrative.
• Revalidate dependencies and acquire current ownership before resuming work.
• Leave a useful next step and preserve unfinished artifacts without hiding their status.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1A request timed out after it was sent. What should the checkpoint say?

   Failed, so send again with a new keyUnknown effect, reconcile the original action identityComplete because the model expected success

2. 2What is missing from a handoff that only says “all tests passed”?

   Answer it, then reveal