Snapshots and inspecting an account

What a snapshot is

When a Portfolio is attached to an account by any path, the platform takes a snapshot: a self-contained, point-in-time copy of every entity required to run the strategy live. The set is fixed:

• The Signals the strategy references
• The Models those Backtests use
• The Backtests inside the Portfolio
• The Portfolio itself

After attachment, the snapshot is what the account trades. It carries its own copies of all four entity types, so the account has everything it needs to run without reaching back into your library for anything.

The snapshot is what trades

Edits to the source entities in your library do not propagate to the account. There is no live-tracking link between the two. Change a Signal, retune a Model, or rebuild a Backtest in your library, and the running account keeps trading the versions frozen in its snapshot.

To make a running account reflect a library change, promote the updated version. Promotion triggers a swap, and a swap replaces the snapshot the account is trading. Because a swap changes what the account holds, it requires the account to be Stopped first. The full mechanics of that handoff live on the promotion and swaps page.

The default is attachment-time freezing: what an account trades is fixed at the moment of attachment, and a library change reaches the account only when you promote a new version and the swap runs.

Snapshot and library are independent

The snapshot is owned by the account, not the library. A snapshot may or may not have matching entities in your library, and that relationship can change over time. Three cases make the independence concrete:

• No library counterpart. An auto-wrapped Portfolio, created when you promote a single Backtest, never existed in your library at all. It lives only inside the account's snapshot.
• Library source deleted. Delete a source entity from your library after attachment, and the snapshot copy continues to exist. The account is unaffected and keeps trading.
• Library source edited. Edit a source entity after attachment, and the snapshot does not see the edit. The library version and the snapshot version are now two distinct things that diverge from each other.

In every case the rule holds: the snapshot belongs to the account. Your library is free to change, be deleted from, or grow, and none of it touches a running account.

Read-only inspection

From inside an account, click any entity in the snapshot, a Signal, a Model, a Backtest, or the Portfolio, and open it in a project view for inspection. That view is locked read-only. You can read every parameter, chart, and result, but you cannot change anything.

To change something, clone the entity. The clone is an ordinary library entity you can edit like any other, and the snapshot is unaffected by the clone. Read-only inspection plus clone is the pattern that lets you study exactly what an account is trading without any risk of altering it.

Open in project

The account's Open in project action opens a new project pre-populated with read-only tabs for the curated set the account uses:

• The Portfolio
• Each Backtest inside the Portfolio
• Each Model those Backtests use

Signals are not opened as top-level tabs. A typical account references many of them, so tabbing every one would bury the entities you actually navigate by. The Signals are still reachable through the References panel, which lists every entity the open tabs depend on, recursively.

All tabs opened this way are read-only, the same lock as inline snapshot inspection. To edit any of them, clone.

Clone to iterate

Cloning forks a snapshot entity into an editable library entity without touching the account, and that fork is what makes iterating on a running strategy safe. When you clone a Backtest out of an account's snapshot, the clone lands in your library as an ordinary, editable entity while the snapshot stays frozen. You edit and run the clone in parallel with the version the account is still trading, so the two never interfere: the account keeps trading its current snapshot the entire time you work on the fork.

If the clone turns out to be the better strategy, it re-enters the account the same way any change does, through promotion. Promoting the clone triggers a swap on the running account, with the promotion and swaps page covering the handoff and its stopped-state requirement. Nothing about the fork reaches the account until that promotion runs, which is why you can iterate freely against a live account without risk to what it holds.

Snapshot history

When a Portfolio is swapped, the previous snapshot is not discarded. The swap event in the account ledger retains access to the prior snapshot, so you can revisit any past Portfolio the account has held. Old snapshots are read-only in the same way the current one is: inspect them freely, clone anything you want to reuse, and the account is untouched.

This makes an account's history fully auditable. Every Portfolio it has ever traded is still openable through the ledger, so you can compare what changed across swaps and pull a past version forward as a clone if a later one underperformed.