Rust adaptation: configuration is described from crates/live/src/node/config.rs and its runtime-support validation.

Live Engine Configuration

LiveNodeConfig is the root native configuration. It combines identity and lifecycle timeouts with cache, message-bus, portfolio, data-engine, risk-engine, execution-engine, event-store, client, and plugin settings. LiveNodeBuilder consumes the configuration, registers factories and strategies, and constructs the kernel-owned node.

Root node settings

The root config includes:

• environment, trader_id, and optional instance_id.
• State load/save and shutdown_on_error switches.
• Connection, reconciliation, portfolio, disconnection, post-stop, and shutdown timeouts.
• Optional cache, message-bus, portfolio, streaming, emulator, and event-store settings.
• Maps of data-client and execution-client configurations.
• Native plugin descriptors.

Sources: crates/live/src/node/config.rs (LiveNodeConfig), crates/live/src/node/builder.rs (LiveNodeBuilder).

Data engine settings

LiveDataEngineConfig controls time-bar interval semantics, close timestamps, partial first bars, build delay, origin offsets, sequence validation, delta buffering, book-derived quotes, external client IDs, and debug logging.

The qsize field exists in the configuration model but the current Rust runtime accepts only its default value. validate_runtime_support rejects non-default queue sizing rather than pretending it is active.

Risk engine settings

LiveRiskEngineConfig controls:

• Optional bypass of pre-trade checks.
• Submit and modify rate limits expressed as limit/HH:MM:SS.
• Per-instrument maximum notional values.
• Debug logging.

Rate-limit and notional strings are parsed during validation. As with the data engine, non-default qsize is currently rejected.

Execution engine and reconciliation

LiveExecEngineConfig owns startup reconciliation and periodic consistency checks. Important fields include:

• Whether reconciliation runs and its startup delay.
• Lookback and optional instrument filters.
• Missing-order generation and external-order filtering.
• In-flight check interval, threshold, and retries.
• Open-order and position consistency intervals, thresholds, and retries.
• Cache load, purge intervals, overfill policy, and own-order-book management.

Snapshot persistence, database purging, and non-default queue size are represented in the config model but rejected where the native runtime does not yet wire the required backing database behavior. This distinction is enforced by validate_runtime_support and covered by tests in the same module.

Event-store configuration

When event_store is present, the caller must also supply an event-store factory through LiveNodeBuilder::with_event_store. The config carries run and recovery settings; the factory constructs the concrete KernelEventStore. Configuration alone does not activate persistence.

Unsupported fields are errors

Before building a node, call:

config.validate_runtime_support()?;

The validator collects unsupported and invalid fields into actionable configuration errors. The current source explicitly rejects unsupported streaming persistence, emulator configuration, loop debugging, several snapshot/database fields, and non-default queue sizes. It also validates plugin paths and hashes, bar-origin keys, instrument identifiers, client-order identifiers, rates, notionals, and reconciliation durations.

Provider-client configuration

data_clients and exec_clients hold typed configuration payloads identified by factory keys. Factories registered on LiveNodeBuilder interpret those values and create clients. Databento supplies a data-client factory; Interactive Brokers supplies data and execution composition.

Secrets should be resolved at the process boundary and passed through the provider’s supported configuration path. Do not serialize credentials into this documentation, state snapshots, or browser-facing configuration.

Startup consequences

Configuration affects startup order:

1. Construct the kernel and register clients.
2. Connect data clients and receive instruments.
3. Flush pending data so the cache is ready.
4. Connect execution clients.
5. Reconcile execution state.
6. Initialize portfolio values.
7. Start actors, strategies, and the live runner.

A timeout is an operational bound, not proof that an external provider reached a healthy state. Readiness probes must observe the resulting client and node state.