Pick the work back up where you left off

Outcome

Save enough context to resume after an interruption: the objective, current result, sources, decisions, open risks, and next step. Use the same checkpoint when handing work to another person or task.

Continuity is more than keeping a process awake. It combines frequent checkpoints, restartable steps, versioned artifacts, tested backups, and concise recovery instructions. The best recovery experience does not depend on reconstructing a long conversation.

Be precise about what follows a user to another device. A project backup can preserve files and written instructions, but it does not automatically recreate local account connections, app permissions, task schedules, credentials, running processes, or machine-specific settings. Verify each dependency separately before claiming a recovered workflow is active.

When to use it

Use this pattern for any task that lasts longer than a focused sitting, changes important files, depends on external systems, has multiple validation stages, or may be handed to another person or task.

Checkpoint more aggressively before deployments, bulk transformations, travel, device migration, long unattended runs, or work with expensive source reads. A brief one-off draft may need only a saved file and a clear name.

Treat continuity as a design requirement before the work begins. A backup created after an incident is not a recovery plan.

Operating pattern

Build continuity in five layers:

1. Atomic steps: Split work into bounded stages that can be rerun safely.
2. Checkpoints: After meaningful milestones, record verified state and the next action.
3. Versioned outputs: Keep source inputs, generated artifacts, and validation receipts identifiable.
4. Backups: Keep a recoverable copy outside the device or storage location that holds the working files, using an approved destination. Verify that the copy is intact.
5. Recovery rehearsal: Periodically restore to a clean location and prove that instructions work.

A checkpoint should be small enough to read quickly and precise enough to resume without the original conversation. Record facts separately from assumptions. Name incomplete or failed checks explicitly.

Preserve the existing workstream owner when resuming. Check the canonical project, current source revision, outstanding approvals, and latest run receipt before creating a new task. If identity or source access cannot be verified on the current device, stop at a review-ready recovery plan rather than guessing.

Automations should be idempotent where practical: rerunning the same stage does not duplicate messages, corrupt state, or overwrite a newer result. Use temporary outputs and promote only after validation.

Copyable implementation

# Restart card

Goal: [single objective]
Owner: [role]
Last verified at: [timestamp and time zone]

Verified current state:
- [artifact/revision and evidence]
- [check passed and result]

Decisions locked:
- [decision and rationale]

Incomplete or unverified:
- [gap, failed check, or dependency]

Connections and schedules:
- Approved source access verified: [yes / no / not tested]
- Existing owner or task verified: [yes / no / not tested]
- Any recurring schedule verified: [yes / no / not configured]

Resume in this order:
1. Re-read [canonical source].
2. Confirm [currentness or dependency].
3. Run [bounded next step].
4. Validate with [named check].

Do not:
- [external, destructive, or stale-state action]

Approval required before:
- [send, publish, deploy, access change, destructive action]

Recovery locations:
- Primary artifact: [portable pointer]
- Backup: [portable pointer and backup date]
- Integrity check: [method]

Create a fresh card when the goal changes, the work changes lanes, or three substantial implementation or validation checkpoints have passed.

Example

For example, a research group builds a recurring briefing from several public datasets. Each run writes to a new versioned directory, records source retrieval times, and validates the combined output before updating a latest pointer. After analysis and layout milestones, ChatGPT Work refreshes the restart card.

During an interrupted run, a new task reads the card, confirms that the sources have not changed, and reruns only the incomplete layout stage. It does not repeat the analysis or publish the briefing. Later, the team rehearses recovery by restoring the project backup into a clean temporary location, rebuilding the briefing, and comparing checksums for stable inputs.

Approval boundary

Permission to checkpoint or back up local work does not authorize copying sensitive material to an unapproved destination. Storage location, retention, encryption, and access policy remain human and organizational decisions.

Require approval before overwriting shared state, restoring over a current workspace, changing backup retention, exporting restricted data, publishing recovered artifacts, or deleting old versions. During recovery, default to restoring into a separate location and comparing before replacement.

Validation

Prove continuity rather than assuming it:

• Resume from the restart card in a fresh task.
• Verify existing ownership, source permissions, and any approved schedule independently.
• Interrupt a non-destructive test run and rerun the incomplete stage.
• Confirm reruns do not duplicate external actions.
• Restore a backup into a clean location.
• Verify expected files, metadata, and integrity checks.
• Confirm secrets and restricted data are excluded or handled by approved controls.
• Measure recovery time and record missing instructions.

Validate both the artifact and its dependencies. A restored project that cannot locate its required runtime or source contract is not fully recoverable.

Failure modes

Common failures are giant checkpoints that merely copy chat history, backups that were never restored, a latest folder with no provenance, and scripts that overwrite their only good output. Another is confusing synchronization with backup: synchronized corruption or deletion can propagate everywhere.

Watch for restart cards that claim checks passed without evidence, recovery instructions tied to one person’s machine, assumed account or scheduler migration, and unattended runs whose external side effects are not idempotent. Finally, do not let continuity become indefinite accumulation. Use an approved retention policy, but delete only with clear scope and recovery awareness.