Product model

Revisions

A revision is a specific saved version of a strategy. It captures the strategy logic, settings, and configuration exactly as they existed at the moment that revision was created.

In practice, revisions are the unit you use to test and run strategies in Structure. You do not backtest “a strategy in general” and you do not start “the idea in the abstract”. You run a backtest job for a specific revision, and when you start a live deployment, you select a specific revision for that deployment.

Revision lifecycle to runtime selection Revision-owned logic and settings become a selected runtime artifact; Strategy Variable values are supplied by the run.

Editable work

Draft revision Editable strategy graph and state-machine logic

Revision-owned

Validation state DAG, types, actions, venue, instrument

Compile output Result attached to the saved revision

Compiled revision artifact/binary Runtime form used by the strategy engine

Run-provided

Strategy Variable values Concrete values for exposed node parameters

Path settings Account, balances, historical range, or assumptions

Runtime path

Live deployment Long-running live venue operation

Paper deployment Long-running simulated execution

Backtest job Finite historical evaluation

Revision-owned parameters Venue and instrument belong to the immutable revision, alongside DAG logic, state-machine logic, fixed node parameters, validation state, and compile output.

Run-provided values Strategy Variable values can change per live deployment, paper deployment, or backtest job without changing immutable revision logic.

Legend

Results Recorded metrics, telemetry, and review context.
Live path Long-running live deployment or live venue boundary.
Paper path Long-running paper deployment boundary.
Backtest path Finite backtest job boundary.
Revision-owned Immutable strategy revision logic and settings.
Run settings Run-provided values, balances, ranges, or assumptions.
Compiled artifact Runtime artifact or binary attached to a validated revision.

Why revisions exist

Structure uses revisions so that strategy development remains traceable over time. As a strategy evolves, you may change thresholds, add filters, modify state transitions, or redesign parts of the graph. If those changes were applied directly to a single mutable strategy definition, it would become much harder to answer basic questions later:

Which logic produced a given backtest job?
Which revision powered a live deployment during a specific period?
What changed between one iteration and the next?

Revisions solve that by turning each meaningful version into a distinct object with its own identity and history.

Revisions are immutable

Once a revision has been created, it is treated as immutable. If you want to change the strategy, you create a new revision rather than editing an existing one in place.

This matters for a few reasons:

Backtest jobs stay reproducible because the logic they reference does not silently change later.
Live deployments stay auditable because you can identify exactly which revision powered the deployment.
Iteration stays clearer because each new revision reflects a deliberate change.

This does not mean your work must be perfectly final before you save it. It means that once a revision becomes a saved version, Structure treats it as a stable reference point. That stable reference point includes the validation state, compile output, and compiled revision artifact used for evaluation.

Draft and saved revisions

When working on a strategy, you may encounter a special Draft revision. Draft is the editable working area where you can adjust the graph and other revision-level settings before creating a saved revision.

This gives you a place to experiment without immediately creating a new version. Once the draft is in a good state and passes validation, you can create a revision from it.

Because saved revisions are immutable, making a meaningful change after that point means returning to a draft-like workflow and creating another revision. If you attempt to edit in a way that conflicts with the current draft state, Structure may warn you that continuing will replace the draft’s work in progress.

What a revision contains

A revision typically includes the parts of the strategy that define how it behaves, such as:

The strategy graph and its calculations.
State definitions and transitions.
Target position logic.
Memory and reusable groups used by the strategy.
Revision-specific settings and parameters.
Validation state and compile output.
The compiled revision artifact used by the strategy engine.

The exact editing experience is covered in the strategy anatomy pages. At a conceptual level, the key point is that a revision represents one complete, runnable definition of the strategy.

Revisions, deployments, and jobs

A revision is the saved strategy definition. Deployments and jobs are the runtime objects that use that revision.

Live deployments and paper deployments use deployment lifecycle states:

drafting: the deployment parameters are being specified by the user.
provisioning: Structure is preparing the selected revision and runtime path.
running: the deployment is active.
stopping: Structure is shutting the deployment down.
stopped: the deployment is no longer running.
failed: the deployment could not start or continue.

Backtest jobs use job lifecycle states:

drafting: the user is filling out the job parameters.
provisioning: Structure is preparing the selected revision and runtime path.
running: historical data is driving the selected revision.
completed: the job finished and results are available.
failed: the job stopped before completion and exposes an error reason where available.

This separation is important because a single strategy can have many revisions, many backtest jobs, and multiple deployment records over time.

How revisions relate to strategies

A strategy is the long-lived container for a trading idea. A revision is one version of that idea.

That means:

One strategy can have many revisions over time.
A revision belongs to exactly one strategy.
The strategy can show both its latest revision and its currently running revision, if any.

This separation lets you keep a stable top-level object for the idea while still preserving a history of concrete versions underneath it.

How revisions relate to backtest jobs and live deployments

Revisions connect directly to two of the most important workflows in Structure.

First, backtest jobs are tied to specific revisions. This makes results easier to interpret because each job points to a fixed version of the strategy.

Second, live deployments are also tied to specific revisions. When you start a live deployment, Structure uses the selected revision for live operation.

Because compile output stays attached to the saved revision, users can connect runtime behavior back to the validated and compiled version that Structure evaluated.

This is why revisions are such an important concept in the app: