Reference

Runtime Workflows

Runtime workflows define how a trading system starts, follows private events, repairs state after reconnects, and returns to event-driven planning. REST Hydration is part of those workflows, not a substitute for healthy private streams.

Event-Driven Loop

Private events update Account State, record the affected scope, give related events a short bounded window to arrive, and one workflow owner chooses one action family. Accepted mutations stay pending confirmation until private confirmation or scoped recovery, and REST state fetches happen only at trust boundaries.

Private event -> Account State update -> affected scope -> event-burst wait -> one action family -> pending confirmation -> private confirmation.
Do not enter REST recovery just because private order, execution, fill, or position events arrived. If the private stream is healthy and Account State has ingested the matching order evidence plus the matching position or account evidence, continue from private-stream account state without REST hydration. For products without exchange-provided position rows, locally derived position evidence fills the same role.
Give related private events a short bounded window to settle before planning dependent actions from Account State.
For implementation order, artifacts, and conformance checks, use Exchange State Management.

Startup and Reconnect

REST Hydration initializes or repairs the state needed before normal event-driven planning can be trusted.

Startup may hydrate filters, account, order, position, balance, and risk state before private events can safely drive planning.
Reconnect should repair only the affected account, product, symbol, or side scope unless broader evidence is missing or contradictory.
After startup or reconnect hydration, buffered private events should be replayed into Account State before normal workflows resume.

Operational Gates

Risk Gate and Safe Command are runtime workflow rules, not execution-mode values.

Risk gates block startup, signal, order-intent, or submitter paths when current market, stream, account, exposure, or operator-stop conditions are unsafe.
Safe commands keep diagnostic and readback tasks in non-writing runtime behavior, regardless of the shell environment.

Recovery Path

Scoped Recovery is for uncertainty, not routine event handling.

Use scoped REST hydration for startup, restart, reconnect, stream exception or gap, missing prerequisites such as filters, unknown submit/cancel/amend outcomes, timeouts, sync-required or not-ready state, conflicting evidence, and explicit recovery. It is not the ordinary response to every healthy private event or ordinary pending confirmation.
RecoveryRequired or syncRequired blocks normal cleanup, protective, DCA, and EXECUTION_MODE=DEMO, TESTNET, or LIVE submission until scoped REST hydration plus buffered replay restores trusted account state. Deterministic stale-target no-ops avoid entering recovery when account state already proves convergence.