Orders

What Orders is for

Orders shows the order lifecycle reported for the selected account or deployment, with Fills directly below it. Use this tab to trace what Arizmic requested, what the provider accepted, and what actually executed.

An order is not a fill, and a missing acknowledgement is not a rejection.

Choose the correct scope

Confirm the selected deployment and scope in the operating strip before reading the tables. Account scope can include external or unattributed activity. Deployment scope should include only orders and fills attributed to the selected deployment and runtime generation.

For Portfolio deployments, retained rows also preserve the owning member Strategy Configuration and Portfolio coordination decision. The provider order remains an account mutation even when several member decisions contributed to it.

Read the Orders table

The table reports the applicable instrument, ownership, side, requested quantity, remaining quantity, lifecycle state, average price, working notional, filled notional, and update time.

Common lifecycle stages include request creation, durable reservation, provider handoff, acknowledgement, working, partial fill, filled, cancel or replace pending, cancelled, rejected, expired, and unresolved. The exact states shown depend on the provider's supported order lifecycle.

Open a row to inspect its stable Arizmic identity, provider identity when known, source decision, deployment generation, order terms, state changes, and related fills.

Understand durability and handoff

Before an order can reach an external transport, Live retains the deterministic order identity, source lineage, risk decision, and durable mutation reservation required by its recovery contract. Provider handoff follows that reservation.

This ordering prevents a restart from silently forgetting an externally ambiguous mutation. It also means a locally durable request can exist before the provider responds.

Cancel, Flatten, Kill, execution reports, and risk transitions receive priority over ordinary market-data backlog. If the workstation becomes overloaded, Live closes new risk before it silently drops or reorders safety-critical events.

Read Fills as execution facts

The Fills table reports immutable execution events such as instrument, side, quantity, price, fee, liquidity role, and fill time when the provider supplies them.

Partial fills update the remaining order quantity, position, capital, and risk state before a later decision can use that state. Repeated provider delivery must not duplicate a fill.

Paper fills describe the selected Paper venue. Real fills describe provider-reported execution. Neither should be replaced by a modeled queue estimate or chart marker.

Separate Arizmic-owned and external orders

Orders created by Arizmic carry deployment and decision lineage. External or unattributed provider orders remain visible when they affect account truth, but Arizmic does not silently adopt, cancel, replace, or attribute them to a deployment.

An unattributed order can block new risk or reconciliation until the operator resolves its ownership and account effect.

Treat unknown outcomes as incidents

If a submit, cancel, or replace request loses its response, the mutation remains unresolved. Do not retry it from the absence of an acknowledgement.

1. Keep conflicting order entry closed.
2. Open the order inspector and Activity timeline.
3. Refresh the provider order stream and independent open-order snapshot.
4. Match stable client and provider identities where available.
5. Reconcile the final order, fill, and position state.
6. Use only the enabled recovery action.

Provider timeouts remain separate from provider rejections. If the final state cannot be proven, preserve the blocker rather than forcing a terminal label.

Investigate an unexpected fill

Trace the fill in this order:

1. inspect the fill identity and provider time;
2. open its parent order and full lifecycle;
3. open the source entry in Decisions;
4. review the risk and Portfolio coordination outcome;
5. confirm the resulting position in Monitor; and
6. use Activity to place the events in journal order.

If the same fill appears twice, the position does not agree, or event ordering is uncertain, stop new risk and reconcile before taking another action.