Insight Pipes

Insight Pipes turn a trading idea into a controlled sequence of decisions. Use them for position sizing, trading windows, reward-to-risk checks, entry submission and position management. Keep signal generation in the alpha model.

Build a state-specific chain

The current engine states are New, Executed, Filled, Closed, Cancelled and Rejected. Expiry is a reason for an outcome, not a separate Expired state.

For a new insight, a typical chain sets entry intent, establishes protection levels, sizes the position, checks constraints and submits it. For a filled insight, use management pipes for stops, profit taking, scale-out or time-based exits.

The order matters: quantity-to-risk calculations need the relevant price and protection inputs. In AQS, inspect the pipeline hierarchy and each node’s properties before running a backtest.

Custom pipe interface

pub trait InsightPipe {
    fn version(&self) -> &str;
    fn run(
        &mut self,
        ctx: &mut dyn StrategyContext,
        insight: &mut Insight,
    ) -> InsightPipeResult;
}

This is the core interface; the trait also provides optional hooks. InsightPipeResult describes whether the stage passed, whether it succeeded, an optional message and any dependency that must complete first.

Pending is different from failed

Broker commands and required snapshots can be unavailable immediately. The runtime retains a deferred continuation and resumes it when its dependency is ready.

When a custom stage submits an insight, convert the mutation result with the supplied helper:

InsightPipeResult::from_mutation(insight.submit(ctx), self.name())

For an exit stage, use:

InsightPipeResult::from_exit_mutation(insight.close(ctx), self.name())

These are return expressions inside a pipe’s run method. The exit helper prevents later stages issuing another exit in the same turn. Snapshot-dependent logic can use InsightPipeResult::from_read_error to preserve a missing account, position or quote dependency.

Do not discard a mutation result and report success immediately. A request can still be queued or waiting for the broker; its receipt is not confirmation that the order filled.

Built-in components

Component	Purpose
`MarketOrderEntryPipe`	Derive market-entry intent from the available bar history.
`InsightTtlConfigPipe`	Configure how long an unfilled or filled insight may remain active.
`MinimumRiskToRewardPipe`	Validate the proposed risk and reward.
`InsightSubmitPipe`	Check pending-tree capacity and request submission.
`BasicStopLossPipe`	Request an exit when protection is triggered.
`BasicTakeProfitPipe`	Manage full or partial profit-taking exits.

Built-in exit logic handles the applicable execution path. Prefer these components over copying an older bar-only stop or take-profit implementation into a new live strategy.

Quantity and broker capacity

The current sizing tools distinguish an individual order’s maximum size, aggregate symbol exposure and the account’s pending-order limit. Oversized orders may be split into execution fragments; those fragments are not additional logical DCA levels.

Capacity calculations include active and reserved strategy quantities. Other strategies and manual orders can still consume broker capacity, so the broker remains authoritative. See Brokers and Datafeeds.

Validate your changes

Run a backtest, inspect rejected and cancelled insights as well as fills, and read the state history for the reason each stage stopped. Then verify the same configuration with a controlled paper run before using a live execution account.