Make the handoff survive the session

Work through the checks

1. Define the handoff contract

   Name the required files, the intended recipient, the expected format and the checks that matter. Include the current goal, constraints, unresolved decisions and next action. A checksum alone cannot establish completeness.

2. Save outside the working session

   Use an approved repository or durable file store. Preserve originals. Record the exact version, file identity and digest. Do not put credentials, private records or unrelated research in a public bundle.

3. Verify the receiving copy

   Retrieve the saved version through its supported access route, compare its digest, extract it safely and run the relevant checks. Confirm the intended recipient can access it. A successful upload receipt is not a restore test.

4. Record the outcome honestly

   Report checks as pass, fail or unavailable. A required failure means reject. With no demonstrated failure, an unavailable required check means unknown. Accept only with positive evidence for every required check.

5. Close the loop

   Provide the attachment or verified link, a short description, the version and any important limits. Keep a recovery note pointing to that same source of truth. Do not call local-only work delivered.

What would count as success?

1. The stored bytes match the validated candidate. Evidence for check 1
2. Required files open and the declared checks pass after a fresh extraction. Evidence for check 2
3. Recipient access is verified and remaining unknowns are disclosed. Evidence for check 3

Evidence to bring back

Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.

1. The stored bytes match the validated candidate.

   Proposed evidence for acceptance check 1. No result has been observed here.

   Bring back: Record the exact saved file identity, version and digest, then the digest of a freshly retrieved copy. Keep the candidate-to-retrieved comparison with the handoff.

   Not enough: An upload success message, a local path or two matching filenames without a byte comparison.

2. Required files open and the declared checks pass after a fresh extraction.

   Proposed evidence for acceptance check 2. No result has been observed here.

   Bring back: Keep a short inventory and the actual open, extraction or build results from the retrieved copy, tied to that version. Include failed and unavailable checks.

   Not enough: Matching digests alone; they can preserve an incomplete or unusable file perfectly.

3. Recipient access is verified and remaining unknowns are disclosed.

   Proposed evidence for acceptance check 3. No result has been observed here.

   Bring back: Record the intended recipient and the authorized access check, including when it was made and any remaining limits. Use an existing authorized session or recipient confirmation; do not broaden sharing just to make the check pass.

   Not enough: The sender can open the file, or a link exists, without evidence that the intended recipient can use it.

What this does not establish

This is an editorial checklist, not a tested backup service. Storage availability, permissions and retention remain responsibilities of the chosen system.

Reference links

These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.

• Git documentation: distributed workflows (Online source)

  Background on distributed version-control workflows. It does not establish a particular repository backup or successful restoration.

  Source review date: 2026-11-10

• NIST: updated contingency planning guide (Online source)

  Contingency-planning background, including recovery planning. This worksheet is not a NIST certification or a tested implementation of that guidance.

  Source review date: 2026-11-10

If another problem remains

Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.

• Only if: The saved files are usable, but a fresh reader still cannot identify the next step or current limits.

  Keep memory useful without losing the rules

  Improve the continuity note without creating a competing copy of the artifact.

• Only if: The handoff contains an action that may have completed before the session ended.

  Check the outcome before retrying

  Reconcile that operation before a new session repeats it.