Decisions

What Decisions is for

Decisions explains what the deployed Strategy or Portfolio logic requested and what happened before an order could be submitted. It is the bridge between an evaluation and the order lifecycle.

A decision is not an order or a fill. Use Orders to confirm provider-facing execution.

Read the decision list

Each retained row identifies the applicable instrument, side, quantity, order type, decision status, and decision time. Open a row for the exact source, evaluation context, parameters, market-data frontier, risk snapshot, and downstream order lineage that are available for that decision.

The selected account or deployment scope applies to the entire list. Confirm it before comparing decisions from different sessions.

Understand Strategy decisions

For a Strategy deployment, the record connects the immutable Strategy Configuration and runtime state to its proposed order intent. It distinguishes:

• an evaluation that produced no intent;
• an intent that was admitted;
• an intent changed or blocked by sizing, instrument, session, or risk rules;
• a Shadow decision that was intentionally not submitted; and
• an admitted intent linked to its durable order mutation.

The record describes the actual deployed version. Editing the Strategy later does not rewrite historical decisions.

Understand Portfolio decisions

For a Portfolio deployment, Decisions preserves two connected layers:

1. the member Strategy Configuration that produced the intent; and
2. the Portfolio coordination outcome before the order boundary.

The coordination detail can include shared-capital admission, allocation, priority, simultaneous or opposing intent handling, exposure and drawdown checks, resizing, displacement, rejection, and the final account-level command.

Member identity remains visible through orders, fills, positions, risk actions, and Activity. The page does not present each member as an independent account when capital and risk are coordinated.

Read Shadow correctly

Shadow records what the deployed logic would have requested under its current inputs and gates, but it does not submit an order or create a simulated provider fill. Use it to inspect logic, timing, lineage, and risk decisions without confusing the output with Paper execution.

Follow one decision downstream

When a decision should have produced an order:

1. verify its status and any blocker;
2. confirm the source revision and instrument binding;
3. review the sizing and risk snapshot;
4. for Portfolio, review the coordination outcome;
5. follow the stable order link into Orders; and
6. confirm fills, position changes, and Activity events.

The absence of a provider order can be correct when the decision was Shadow-only, blocked before durable mutation, resized to zero by Portfolio policy, or held while reconciliation closed order entry.

Investigate a blocked decision

Read the first blocker and the complete blocker list. Typical owners include:

• stale or unavailable market data;
• unresolved provider session or account state;
• unsupported instrument, order, quantity, or entitlement;
• source warm-up or evaluation not ready;
• risk-profile limits;
• Portfolio capital, conflict, or member-state rules;
• an unresolved prior mutation; or
• reconciliation, Kill, or recovery state.

Correct the owning condition rather than altering the Strategy merely to make the blocker disappear.

Compare decisions safely

Compare decisions only when the source version, runtime generation, provider environment, account, instrument binding, market-data sequence, risk profile, and Portfolio policy are known. A matching timestamp or display label is not enough to establish identical context.

Use Activity for the durable event order when several evaluations, fills, commands, or risk callbacks share a close timestamp.