Structure's strategy model

The philosophy behind Structure strategies

Structure is built around the idea that an automated strategy should be easy to reason about as it evolves from research to live trading. Instead of treating a strategy as a single block of logic that mixes calculations, intent, and execution behavior, Structure separates those concerns into distinct layers. The goal is to make trading logic as clear as possible while handling operational complexity separately.

In practice, this means Structure is designed to help you focus on the trading idea itself:

Which inputs matter?
Which calculations or signals should be derived from them?
Under which conditions should the strategy change its view?
What exposure should each view imply?

At a high level, the platform encourages you to define what information the strategy uses, what conclusions it derives from that information, what state or intent it should have, and what position that state should correspond to.

By keeping those questions explicit, Structure aims to support a more disciplined workflow for building and iterating on strategies. It becomes easier to compare revisions, explain behavior, and understand the effect of a change. That matters both during research, where you want cleaner experimentation, and during live trading, where you want clearer operational understanding.

This does not remove complexity from trading itself. Rather, it tries to place complexity in the right layer. Strategy design should describe the decision-making logic of the strategy; the mechanics of moving an account toward the desired position should not obscure that logic.

What a strategy is composed of

On Structure, a strategy revision is typically built from a small set of core ingredients that work together.

The first is the logic layer, where you define the values and computations the strategy depends on. This is where market inputs, derived values, and reusable building blocks come together to produce the signals or conditions that matter to your idea.

The second is the state layer. Rather than thinking only in terms of placing orders, Structure encourages you to model a strategy as a set of possible states, such as being long, short, flat, paused, or any other meaningful mode for that strategy. Those states represent the strategy’s current intent.

The third is the target position layer. Once a strategy is in a given state, that state maps to the position the strategy wants to hold. For example, one state may correspond to no exposure, while another corresponds to a long or short target of a specific size.

Supporting these layers are other pieces of the strategy model, including:

Memory, for values that need to persist across evaluations.
Groups, for reusable logic that can be shared across strategies or parts of a strategy.
Versioned revisions, so changes to logic are tracked as new immutable versions rather than silently modifying a live definition.

Together, these pieces form a strategy model that is modular enough to be understandable without requiring the user to think in low-level system terms.

Why Structure is designed this way

This design exists to make strategies easier to build, test, and operate over time.

When calculations, state transitions, and execution intent are separated, each part is easier to inspect on its own. If a signal is incorrect, you can focus on the logic that produced it. If a strategy is in the wrong state, you can inspect the conditions that led there. If the resulting position is not what you expected, you can look at how states map to targets.

That separation is also useful for iteration. A strategy rarely stays unchanged for long. You may adjust a threshold, add a filter, refine a state transition, or test a different sizing rule. Structure’s model is intended to make those changes more traceable, so that a new revision reflects a clear change in logic rather than an ambiguous rewrite of a larger system.

It also helps with reproducibility. Because revisions are versioned and backtests are tied to specific revisions, it is easier to compare historical results with the exact logic that produced them. That supports a more rigorous research process and reduces ambiguity when moving from backtesting to live trading.

Finally, this model reflects a broader product goal: reducing boilerplate without turning strategies into black boxes. Structure tries to remove infrastructure and execution burden from the strategy author while still keeping the important parts of the strategy visible and inspectable.

In practice

As you use Structure, you will see this model appear throughout the product. The interface asks you to define strategy logic, states, and targets separately because those are treated as distinct parts of the strategy, not as one undifferentiated workflow.

If you are new to the platform, a useful way to think about it is:

Define the information and computations that matter to your strategy.
Decide which states the strategy can be in.
Specify which conditions move the strategy between those states.
Map each state to the position the strategy should try to hold.

From there, Structure can use that definition consistently across revisioning, backtesting, and live operation.

If you want to explore the details behind this model, continue with: