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 that says “nearly done, just finish the order” leaves the next worker guessing whether the amendment was approved, whether it was sent, whether the service returned a receipt and which order revision was checked. Each of those answers changes what the next worker is allowed to do.

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 secrets or every retrieved document. Store controlled references that a resumed worker can resolve under its current permissions. Keep in mind that a hash or record ID can still identify sensitive customer work; it is not anonymous by default, and it is not automatically safe to send to an external tracing service.

Choosing work from dependencies and current evidence

A feature ledger is useful when it distinguishes these states:

These are distinctions in meaning; they do not have to live in a single 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.

Pick a small ready task whose dependencies are satisfied. If the browser cannot start because its fixture is missing, editing some unrelated feature does nothing about 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. Reading an old checkpoint does not give a new worker any authority; it must obtain current access and ownership before executing a new operation.

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.

That is enough to choose the next action, and it stops 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 end to a session preserves owned work, names running processes and records unresolved effects. It does not mean 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. Background processes nobody knows about 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. Starting a new conversation, or working with a smaller context window, does not change what happened in the external service.

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 is still useful history, but it applies only to 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