Strategies and related entities

This page describes the main entities you encounter around strategies in Structure and how they connect. It is meant as a map of the objects you see in the app, not a detailed explanation of strategy design or revision behavior.

If you want the broader conceptual model first, start with Structure’s strategy model. If you want a deeper explanation of saved versions, statuses, and immutability, see Revisions.

The main entities

At a high level, the strategy side of Structure is organized around a few core objects:

Strategy: the long-lived container for a trading idea.
Revision: a specific saved version of that strategy.
Trading account: the account or venue connection a live revision trades through.
Backtest: a historical simulation tied to a specific revision.

These objects are related, but they do not all serve the same role. Separating them helps Structure keep research, versioning, and live operation easier to reason about.

Strategy

A strategy is the top-level object that groups together one trading idea and everything that belongs to it over time.

A strategy typically includes:

A name and description.
Tags or other organizational metadata.
A collection of revisions.
References to the latest revision and the currently running revision, if any.
Links to related backtests, accounts, and activity through its revisions.

You can think of the strategy as the durable home for the idea itself. It stays the same even as the underlying logic evolves through new revisions.

Revision

A revision is a specific saved version of a strategy. It is the object that captures the strategy logic, settings, and other revision-level configuration at one point in time.

Revisions are the unit that Structure uses for both simulation and live execution:

You backtest a revision.
You start and stop a revision.
Revision statuses such as stopped, baking, or running apply to the revision, not to the abstract strategy idea.

Each revision belongs to exactly one strategy, while one strategy can have many revisions over time.

For the detailed version of this topic, including draft behavior and immutability, see Revisions.

Trading accounts

A trading account is the concrete account Structure uses to interact with a venue on your behalf. Depending on the venue, this may be a wallet, subaccount, or API-backed exchange account.

Trading accounts matter here because live revisions do not trade in isolation. They act through assigned accounts.

From a relationship point of view:

Trading accounts belong to the user.
Strategies use assigned trading accounts through their running revisions.
Account health, balances, and open positions influence how safely a revision can operate.

This separation allows you to keep strategy logic distinct from venue connectivity and account ownership.

Backtests

A backtest is a historical simulation of a specific revision over a chosen configuration and time range.

Backtests are related to strategies through revisions:

A backtest belongs to one revision.
That revision belongs to one strategy.
Multiple backtests can be run for the same revision with different arguments or periods.

This structure makes backtests easier to interpret because each result points back to a fixed version of the strategy.

How the entities relate

The relationships between these objects can be summarized simply:

A user can own many strategies.
A strategy can have many revisions.
A revision belongs to one strategy.
A revision can be backtested many times.
A live revision can trade through one or more assigned trading accounts.

In practice, this means the strategy is the parent object, while revisions are the executable versions beneath it. Backtests and live operation both attach to revisions, and trading accounts are the real-world accounts those live revisions use.

Common lifecycle

Most strategy work in Structure follows roughly this pattern:

You create a strategy as the container for a new trading idea.
You create a revision that defines one saved version of that idea.
You backtest that revision to evaluate it on historical data.
You assign trading accounts and start a chosen revision live.
You create additional revisions as the strategy evolves.

This lifecycle is useful because it separates three different kinds of change:

The idea can persist as one strategy.
The implementation can evolve through revisions.
The evaluation and operation of that implementation can happen through backtests and live runs.

Why this model is useful

This structure helps keep the app understandable as strategies become more complex.

It gives you:

Organization, because related revisions stay grouped under one strategy.
Traceability, because backtests and live runs point to specific saved revisions.
Operational clarity, because trading accounts remain separate from strategy definition.

That separation also makes it easier to answer practical questions in the app, such as:

Which version of this strategy is currently running?
Which revision produced this backtest?
Which accounts are being used by this live strategy?
What changed between one saved version and the next?