---
title: "Runtime Workflows for AI Trading Systems | Siebly"
description: "Reference for startup hydration, reconnect repair, WebSocket-first state, REST hydration boundaries, scoped recovery, and private event-driven workflows."
canonical: "https://siebly.io/reference/runtime-workflows"
---

# 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](https://siebly.io/reference/glossary#rest-hydration) is part of those workflows, not a substitute for healthy private streams.

## Event-Driven Loop

Private events update [Account State](https://siebly.io/reference/glossary#accountstate), record the [affected scope](https://siebly.io/reference/glossary#affected-scope), give related events a short bounded window to arrive, and one [workflow owner](https://siebly.io/reference/glossary#workflow-owner) chooses one [action family](https://siebly.io/reference/glossary#action-family). Accepted mutations stay [pending confirmation](https://siebly.io/reference/glossary#pending-confirmation) until [private confirmation](https://siebly.io/reference/glossary#private-stream-confirmation) or [scoped recovery](https://siebly.io/reference/glossary#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](https://siebly.io/reference/glossary#accountstate) 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](/ai/exchange-state).

## Startup and Reconnect

[REST Hydration](https://siebly.io/reference/glossary#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](https://siebly.io/reference/glossary#risk-gate) and [Safe Command](https://siebly.io/reference/glossary#safe-command) are runtime workflow rules, not execution-mode values.

- [Risk gates](https://siebly.io/reference/glossary#risk-gate) block startup, signal, order-intent, or submitter paths when current market, stream, account, exposure, or operator-stop conditions are unsafe.
- [Safe commands](https://siebly.io/reference/glossary#safe-command) keep diagnostic and readback tasks in non-writing runtime behavior, regardless of the shell environment.

## Recovery Path

[Scoped Recovery](https://siebly.io/reference/glossary#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](https://siebly.io/reference/glossary#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.

## Related Terms

- [Event-Driven Workflow](/reference/glossary#event-driven-workflow): An architecture where private events drive the main workflow.
- [Affected Scope](/reference/glossary#affected-scope): The smallest account, product, symbol, side, or position scope that changed and needs reconciliation.
- [Event Burst Wait](/reference/glossary#event-burst-wait): A short bounded delay after applying private events to account state, used to give related order, fill, position, and wallet events time to arrive before planning.
- [Workflow Owner](/reference/glossary#workflow-owner): The single runtime owner that drains affected scopes and serializes replay, planning, submission, and follow-up reconciliation for a product or account.
- [Action Family](/reference/glossary#action-family): The one kind of action a reconciliation pass chooses before letting account state settle again: recovery, cleanup, protective, DCA, noop, or blocked.
- [REST Hydration](/reference/glossary#rest-hydration): A scoped REST read that initializes or repairs local state. It is for startup, reconnect, missing prerequisites, unknown outcomes, or conflicting evidence, not healthy-event polling.
- [Scoped Recovery](/reference/glossary#scoped-recovery): A bounded state repair for the affected account/product/symbol/side scope after reconnect, timeout, unknown outcome, missing prerequisites, or conflicting evidence. For app-owned order uncertainty, this can include cancelling owned orders for the affected scope, then resetting expected orders from trusted account state.
- [Readiness Gate](/reference/glossary#readiness-gate): A runtime latch that prevents downstream work until the required subscriptions, acknowledgements, REST hydration or backfill, buffered replay, and state-trust prerequisites are complete.
- [Risk Gate](/reference/glossary#risk-gate): A deterministic condition that blocks a signal, order intent, order submission, replacement, or startup path when market, account, exposure, loss, stream, or operator-stop conditions are unsafe.
- [Safe Command](/reference/glossary#safe-command): A diagnostic, inspection, verification, or readback command that must force PUBLIC or READ_ONLY_PRIVATE behavior and cannot inherit a write-capable EXECUTION_MODE from the environment.
- [Account State](/reference/glossary#accountstate): The local account-state store used for planning. It tracks orders, fills, positions, balances, filters, and durable context, with trust tracked per subject. After startup, healthy private WebSocket events should keep the store current without routine REST polling.
- [Private Stream Confirmation](/reference/glossary#private-stream-confirmation): Private order, fill, balance, wallet or position evidence that confirms what happened after a submitted request or external account event.
- [Pending Confirmation](/reference/glossary#pending-confirmation): A state after request acceptance where the system has evidence that the exchange received a command, but not enough evidence to plan dependent actions.