Is paused the same as disconnected?
No. Paused describes permission to initiate new workflow actions. Connections may remain active so data, order updates, and monitoring continue.
Trading Systems
Designing Transition Guards for Automated Trading States
Define the conditions that permit run, pause, resume, stop, and failure-recovery transitions in an automated trading system.
How the workflow connects
- 1Receive an authorized transition request
- 2Load persistent runtime and connection state
- 3Evaluate environment-specific guards
- 4Apply side effects and persist the transition
- 5Confirm broker and worker outcomes
Running, paused, and stopped are easy to display. The engineering work lies in deciding when a transition is allowed and what must happen around it. Transition guards prevent a resume with stale data, an accidental live start, or a stop command that hides unresolved broker orders.
Write each transition as a contract
For start, pause, resume, stop, and recover, list the requesting role, valid source states, required configuration, connectivity, data freshness, pending work, resulting state, side effects, and audit event. A request can enter starting or stopping while asynchronous work completes.
Strengthen guards around live enablement
Separate environment selection from runtime state. A system can be stopped but configured for live use. Starting live operation may require explicit enablement, approved configuration version, available credentials, healthy connections, no blocking incident, and a recent reconciliation result.
- Environment and live-enable flag
- Approved strategy and risk configuration
- Fresh market and account data
- Broker session health
- No unresolved blocking incident
Define pause and stop consequences
Pause may prevent new decisions while leaving monitoring and order updates active. Stop may terminate workers after persisting state. Neither action automatically cancels open orders or closes positions unless the client-defined operating policy explicitly requires and authorizes those actions.
Recover through a controlled path
A failed state should record cause, affected components, last known broker state, and required recovery checks. Clear the underlying condition, reconcile uncertain orders or positions, obtain any required authorization, and create a new transition event rather than editing the failure out of history.
Write guards from operating evidence
A transition from ready to enabled may require a valid configuration, approved environment, healthy broker session, fresh account snapshot, synchronized clock, empty reconciliation queue, and an operator with the required authority. Each condition should return a named result so the interface can explain why enablement is blocked.
Do not compress every dependency into healthy. A broker stream can be connected while account data is stale, and a strategy process can be running while live submission is disabled. Component states and overall operating mode answer different questions and should remain visible separately.
| Transition | Required evidence | Blocked result |
|---|---|---|
| Idle → ready | Configuration valid; dependencies initialized | Remain idle with validation errors |
| Ready → enabled | Authorized mode; fresh account; connection healthy | Remain ready and identify failed guard |
| Enabled → paused | Pause request recorded | Stop new requests; define open-order policy |
| Paused → enabled | Pause cause cleared; reconciliation complete | Remain paused pending review |
| Any → stopped | Stop reason and shutdown workflow | Preserve terminal evidence and restart gate |
Treat restart as recovery, not initialization
After a crash or network interruption, local memory cannot establish the current broker state. Recover configuration and durable event history, query the broker for relevant open orders and positions, compare them with local records, and place unresolved differences in a visible state. Automatic submission should remain disabled until the recovery contract passes.
Test invalid transitions as deliberately as valid ones: resume while credentials are expired, enable with stale data, stop during an uncertain submission, or restart with an unmatched open order. The expected result should be a safe state with useful evidence, not merely an exception in a log.
Visual guide
Operating states with guarded movement
Transitions depend on evidence and authority; a process cannot move safely because a timer elapsed or a button was clicked.
- 1
Idle
Configuration may be edited; execution dependencies are not assumed ready.
- 2
Ready
Validation passed, but order submission remains disabled.
- 3
Enabled
Defined workflows may submit under current controls.
- 4
Paused
New submissions stop while monitoring and policy-defined handling continue.
- 5
Recovering
Local and venue state are being compared after interruption.
- 6
Stopped
The workflow is closed with a reason and explicit restart gate.
Practical questions
Questions that often come up
Can a system resume automatically after failure?
Only for explicitly approved recoverable cases with strong checks. Uncertain order or account state usually requires reconciliation and may require human authorization.
Continue exploring
Related projects and tutorials
Work with Sun Cluster
Planning a similar system for your organization?
Sun Cluster engineers automated trading systems with persistent runtime controls, explicit environments, monitoring, and recovery workflows.