Product model
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
Section titled “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.
- Deployment: a long-running instance of a selected revision, either paper or live.
- Trading account: the connected venue account a live deployment uses.
- Backtest job: a finite historical evaluation 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
Section titled “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 any deployment records for the strategy.
- Links to related backtest jobs, 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
Section titled “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 backtest jobs, paper deployments, and live deployments:
- You run a backtest job for a revision.
- You start a paper deployment or live deployment from a revision.
- Deployment lifecycle states belong to deployments. Backtest job lifecycle states belong to jobs.
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.
Deployments
Section titled “Deployments”A deployment is a long-running instance of a selected revision. It is the object Structure uses when a revision keeps evaluating as live market data arrives.
Structure has two deployment paths:
- Paper deployment: evaluates the selected revision against live market data and sends order activity to the Venue Simulator.
- Live deployment: evaluates the selected revision against live market data and sends order activity through a selected trading account.
From a relationship point of view:
- A deployment belongs to one revision.
- That revision belongs to one strategy.
- A paper deployment does not require a connected trading account.
- A live deployment uses a selected trading account.
Keeping deployments separate from revisions matters because the same revision can be evaluated through different paths without changing the saved strategy logic.
Trading accounts
Section titled “Trading accounts”A trading account is the concrete venue account Structure uses for a live deployment on your behalf. Structure is launching first with Hyperliquid, and the product shows venue-specific connection requirements as supported venue coverage expands.
Trading accounts matter here because live deployments do not trade in isolation. They act through selected accounts.
From a relationship point of view:
- Trading accounts belong to the user.
- Live deployments use selected trading accounts.
- Account health, balances, and open positions influence how safely a deployment can operate.
- Withdrawal and transfer permissions are not part of Structure’s launch account model.
This separation allows you to keep strategy logic distinct from venue connectivity and account ownership.
Backtest jobs
Section titled “Backtest jobs”A backtest job is a finite historical evaluation of a specific revision over a chosen historical time range and job configuration.
Backtest jobs are related to strategies through revisions:
- A backtest job belongs to one revision.
- That revision belongs to one strategy.
- Multiple backtest jobs can be run for the same revision with different Strategy Variable values, time ranges, starting balances, fees, slippage, latency, and simulator assumptions.
This structure makes backtest job results easier to interpret because each result points back to a fixed version of the strategy.
How the entities relate
Section titled “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 have many backtest jobs.
- A revision can have many deployments.
- A deployment belongs to one revision.
- A live deployment can trade through a selected trading account.
In practice, this means the strategy is the parent object, while revisions are the executable versions beneath it. Backtest jobs and deployments both attach to revisions, and trading accounts are the real-world accounts live deployments use.
Common lifecycle
Section titled “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 run a backtest job for that revision to evaluate it on historical data.
- You start a paper deployment to observe the chosen revision against live market data with simulated execution.
- You select a connected account and start a live deployment from the chosen revision.
- 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 backtest jobs and deployments.
Why this model is useful
Section titled “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 backtest jobs and deployments 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 revision powers this live deployment?
- Which revision powers this paper deployment?
- Which revision produced this backtest job?
- Which account is being used by this live deployment?
- What changed between one saved version and the next?