Saves, versions, and checkpoints

Saving, version history, and checkpoints protect different parts of your work. A save state tells you whether the current edit reached storage. A version records a snapshot in history. A named checkpoint marks a state you want to find again. Do not confuse a historical preview with the editable current strategy.

Save states

• Dirty means the graph has local changes.
• Saving means storage is in progress.
• Saved means the latest accepted changes are stored.
• Offline, error, or conflict require recovery before you assume the latest edit is stored.

Autosave runs while you edit, and manual Save is available whenever saving is allowed. Before leaving, verify the visible Saved state for your latest change. If the state is Offline, Error, or Conflict, keep the tab open and follow save recovery. A Backtest result refers to the version tested; editing the current graph afterward does not rewrite that result.

Try it here

Practice a save conflict

Understand dirty state, autosave, conflicts, history, and non-destructive restore.

Exercise steps

1. Change the threshold on Condition, then save a local checkpoint.
2. Choose a simulated save outcome. Recovery actions appear when that state requires them.

Start lesson

Versions and recovery entries

History can include the current version, recovery entries, named checkpoints, and technical entries. Ordinary saves and autosaves are recovery records, not named checkpoints. The version selector groups categories; operational saves may be collapsed, and older items use bounded pagination or search. Version retention depends on the current policy and plan, so do not assume every recovery save or checkpoint lasts forever.

Previewing an older version opens it in read-only mode. It does not replace the editable graph; editing and autosave are unavailable there. Use Return to Main to resume current work. If a Backtest opens an exact tested snapshot, treat that preview as historical evidence rather than as a place to modify the strategy.

Restore is non-destructive

Restoring creates a new current version from selected historical content. Start the restore from the Versions tab on the strategy detail page when the selected entry offers the action; the historical editor preview is for inspection. Save or resolve current local changes first. The restore confirmation may disclose retention impact that needs acknowledgment. After success, open the current editor and verify its nodes and settings. The restore operation does not rewrite an old Backtest or silently turn its snapshot into a new run.

For example, save a checkpoint named RSI 55 baseline, change the threshold to 60, and save. The current strategy is now 60, while the named checkpoint lets you inspect the earlier 55 configuration. A restore would create a new current version based on 55; it would not erase the fact that you later tried 60. The checkpoint dialog previews any applicable retention effect before creation.