Live execution

A broker-backed session sends supported requests through the selected adapter. The broker owns acceptance, fills, and account state; a strategy signal or locally accepted request is not proof of a trade.

Verify the connection and instrument

Configure the broker through the workspace's connection settings. At launch, select the intended connection and confirm the actual account environment. Keep credentials out of strategy source and logs.

Check the full instrument identity, supported order types, quantity units, and any adapter-specific requirements. A generic simulation payload is not a universal broker payload. Polymarket requires current market and outcome identity in addition to its family configuration.

Establish an observational baseline

First inspect incoming data, startup logs, and existing account positions with an observation-only strategy. Confirm that the session is using the expected instrument and that displayed timestamps are current.

Before enabling an order path, establish who owns entries and exits and how the strategy treats existing positions and pending orders. A fresh process does not imply an empty account.

Trace requests to outcomes

For each investigated action, retain the decision time, source, requested side and quantity, returned order identity/status, and resulting position or fill. Inspect rejections and partial or delayed outcomes rather than assuming immediate success.

Automation and L3 checks are only part of the path. Broker eligibility, available capital, venue rules, and adapter capability can still prevent the request. For example, modification support differs by adapter.

Operate the runtime and account separately

Pausing, stopping, or terminating a server is not a universal cancel-all or flatten operation. Confirm outstanding orders and positions through the broker/account view even after the runtime stops.

Continue with automation modes, monitoring, and stopping and restarting.