Strategy anatomy

Groups

Some strategies contain logic that is easier to understand when it has a name and a clear boundary. In Structure, that logic can be packaged into groups.

Groups help keep a revision understandable. They let you give graph logic a typed interface, either because the same calculation is reused in more than one place or because a focused calculation is easier to review as a named unit.

Group definitions

Group definitions are available when the context menu is opened outside a container node.

Creating a group definition from the context menu outside a source event container.

Inside the group definition, you define the group’s input and output interface and place nodes just like in a regular source-event graph.

A group definition that calculates spread_perc from ask_price and bid_price.

A good group definition has:

A clear name.
Typed inputs.
Typed outputs.
A focused purpose.
Graph logic that is worth reusing or isolating.

Think of the group definition as a named calculation with an explicit interface. The graph inside the group can be detailed, but the rest of the revision only needs to understand the group’s inputs and outputs.

Group imports

Group imports are available inside a source event container or another group definition.

Placing a group import from the context menu inside a source event container or another group definition.

Group imports are placed like regular functions. The user must pick the group the import refers to and can then hook it to other nodes like any other graph node.

A group import node that compares spread_perc against 0.05 and labels the boolean as wide_spread.

The import must satisfy the group definition’s typed inputs. The import then exposes the group’s typed outputs to the surrounding graph path.

This keeps the group boundary explicit:

If an input type is wrong, validation can catch it.
If a group output feeds a label, branch, memory write, or strategy action, that relationship remains visible.
If the group logic changes in a draft, the revision still goes through validation before it can become a saved revision.

When to use groups

Use groups for logic that has a stable meaning and a clear boundary. That can mean reusable logic, or it can mean a calculation that makes the surrounding graph easier to read when it is packaged behind a name.

Groups are useful for:

Reusing the same signal calculation in more than one graph path.
Reusing the same calculation across multiple source-event containers.
Isolating a complex calculation behind a readable name.
Creating a consistent typed interface for logic that appears in multiple places.
Making a revision easier to inspect by reducing repeated node patterns.

The important test is whether the group makes the strategy easier to reason about from the outside: what it receives, what it returns, and why that calculation belongs together.

Practical takeaway

Use a group definition when you want to package reusable or self-contained graph logic behind a typed interface. Use group imports when you want to place that interface inside a source-event container or another group.

Next step

Once the graph, source events, labels, states, strategy actions, memory, and groups are clear, the next question is how Structure validates and prepares a saved revision for runtime. That is the focus of Validation and compiled revisions.