Strategy anatomy

Validation and compiled revisions

Before Structure evaluates a saved revision, the revision must be valid. Validation and compilation are how Structure turns an editable strategy definition into a stable runtime artifact.

Users do not need to manage compilation directly. The important product idea is that a saved revision carries enough context to be reviewed, compared, and evaluated consistently.

For the system architecture view of this boundary, see Strategy engine and compilation model.

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.

What validation checks

Validation checks that the revision is internally consistent.

Validation can cover:

Graph structure and disconnected logic.
Type compatibility between node outputs and inputs.
Labels used by state transitions and strategy actions.
Source-event containers and graph paths.
Memory reads and writes.
Group input and output interfaces.
State-machine branches and reachable states.
Target-position declarations.
Required Strategy Variable values.
Revision-owned venue and instrument context.

The exact error depends on the revision, but the purpose is stable: Structure should surface problems before a revision is treated as ready for evaluation.

Validation state

Validation state is part of revision traceability. When reviewing a revision, validation state helps answer:

Is this revision ready to evaluate?
Which part of the revision needs correction?
Did a draft change introduce a graph, type, memory, group, state, or action issue?
Is the selected revision the one that produced a backtest job, paper deployment, or live deployment?

A validation error is not only a warning. It is a guide to the boundary that failed. For example, a type error in a target quantity points to the graph label feeding the action. A memory error points to the slot definition, the value being written, or the path that produced that value.

Compile output

After validation, Structure can compile the revision for runtime evaluation. Compile output records the result of preparing the revision.

Compile output matters because it keeps the runtime version tied to the saved revision. When users compare behavior across backtest jobs, paper deployments, and live deployments, they should be able to connect results back to the revision and the compiled form used for evaluation.

Structure constructs validated strategy revisions into Rust code for runtime evaluation. Users do not manage that generated runtime form directly, but compile output remains visible as part of revision traceability.

Compiled revision artifact

A compiled revision artifact or binary is the runtime form of the saved revision. It represents the validated graph, state-machine logic, fixed node parameters, memory definitions, group logic, strategy actions, and the revision’s venue and instrument.

Users do not edit the compiled artifact directly. Users edit drafts, save revisions, resolve validation errors, and start live deployments, paper deployments, or backtest jobs from selected revisions.

This separation is what keeps revision behavior stable:

A draft can change while a saved revision remains fixed.
A backtest job can point to the exact revision it evaluated.
A live deployment can show which revision it is using.
A result can be interpreted with its revision, Strategy Variable values, runtime path, and assumptions attached.

What changes require a new revision

Saved revisions are immutable. To change the strategy, create a new revision.

Changes that belong in a new revision include:

Graph logic changes.
State-machine changes.
Strategy action changes.
Fixed node parameter changes.
Memory slot changes.
Group definition or import changes.
Revision-owned venue or instrument changes.

Strategy Variable values are run-provided values. They can vary by live deployment, paper deployment, or backtest job without changing the revision’s fixed logic.

Practical takeaway

Validation makes the revision coherent. Compilation prepares the revision for runtime evaluation. The compiled revision artifact keeps the saved strategy definition tied to what Structure evaluates.

Together, those boundaries make a strategy revision traceable from draft, to saved revision, to backtest job, paper deployment, or live deployment.