Glossary

Vike Trader's vocabulary is small and precise, and most of it is enforced by a test rather than described in prose. Each entry below names the code symbol that is the authority for the word and links to the page that explains it. A word with more than one sense gets every sense it carries.

Arming and mounting

• ceiling — the per-venue arming tier in policy.toml's [venues] table, a vike_config::VenueMode ordered paper < demo < live, which vike_mount::make_engine consults before any credential is read. It can only refuse: VenueMode::cap is min, never max, so bybit = "live" declines to stop bybit going live rather than putting it there, and a box with no table mounts every venue paper. The word also names vike_config::Policy as a whole — the hard ceilings, the one settings type with neither an environment nor a CLI layer. → Risk and arming, policy.
• arming — taking a venue past paper. Two gates decide it, in order: the ceiling, then the credential gate — present {VENUE}_DEMO_* keys spawn a real execution client, absent ones keep the venue paper; crates/vike-bridge-core/src/lib.rs calls its credentials module the absent-credentials-is-the-live-gate authority. → Risk and arming.
• paper — VenueMode::Paper: simulated fills against the local paper exchange, no credential used, no order leaving the process, the default for every venue. The exchange is vike_paper::PaperExecutionClient, which fills a resting book with the backtest engine's own public fill primitives, so backtest == paper is by construction. → The paper exchange.
• mount — three related things. A venue mount is what vike_mount::make_engine builds: one type-erased ExecutionEngine for a venue and symbol plus an optional ReconClient. A strategy mount is a strategy on a (venue, symbol, interval) triple, whose identity crates/vike-core/src/strategy_state.rs's mount_id_of derives deterministically (binance__BTC_USDT__1m). A runtime mount is one added to a running core over the wire (Command::MountStrategy carrying a MountSpec) and recorded so it survives a restart. → Mounting, Accounts, Venues.
• sidecar — a JSON file the core writes beside its state through a temp-write, fsync and rename: <state_dir>/<mount_id>.json for a strategy's durable state, runtime_mounts.json for the runtime mount topology. Both sit behind the opt-in CoreConfig::state_dir and read fail-open, so a corrupt one warns rather than refusing a boot. → Mounting.
• run — in the live core, a RunProfile: the single TOML artifact that names a full runtime assembly — event source, broker, sinks, risk and guard stack — so backtest, paper and live are one auditable file. In backtesting, what a finished run leaves behind: one directory under <project>/user_data/runs/ holding a common manifest beside a report only that run's kind understands. vike-run is the crate that mounts a strategy on the production core and feeds it. → Mounting, Run profiles, Runs on disk.

Inside the core

• fold — applying one event to state on the single-writer thread. ExecutionEngine::on_event folds the venue stream — bare fills into the account, lifecycle events through the ManagedOrder state machine — and answers with a Fold verdict: Applied when state changed, Dropped for an unknown client-order-id, an illegal transition, a reconnect replay, an event for a symbol or venue this engine does not own, or a non-finite venue number, and nothing downstream may treat a dropped event as having happened. The fold loop is the thread the latency gate measures. In reconciliation the verb is the same: a policy decides fold-versus-hold per divergence. → The execution core, The event bus, The latency gate, Policies.
• lane — one of the ingest channels into the core, each with its own loss discipline: exec events are lossless and back-pressure the venue task, commands try_send so the GUI never blocks, market data rides a latest-wins conflation slot plus one marker; the bar lanes (BarSeed/BarClose) and the tick lanes (quote, trade, book) are lossless too. The producer types live in crates/vike-exec/src/lanes.rs, one crate below the core that drains them. Two narrower uses: the emulator's PriceLane (Last or Mark) names which price series checks a conditional, and the backtester's queue lane is the opt-in queue-position fill path. → Ingest lanes, The execution core, Emulated orders, The queue lane.
• snapshot — CoreSnapshot, the immutable state view the core publishes to the GUI through an arc-swap cell. The GUI is a lossy downstream observer that reads the latest on repaint and can never back-pressure the core; the build is coalesced, never per-event. → Portfolio and snapshot.
• halt — TradingState::Halted, under which the RiskGate admits only a position-covered reduce (vike_model::is_covered_reduce) and denies every opening order; also the halt sentinel file every ExecutionClient consults, with crates/vike-exec/src/halt.rs the one predicate for what an engaged halt lets out. Safe-state is the halt the core enters by itself when a handler panics: halted, a best-effort cancel of every non-terminal working order, the fault surfaced in the snapshot, the engine never traded on again until restart. → Halt, The execution core, The dead-man's switches.
• dead-man's switch — two of them, with opposite defaults because they read opposite evidence. The connection one (vike_core::LinkDeadManConfig, policy.toml's link_deadman_grace_ms, armed when the key is absent, 0 the only off) trips on a link a venue's own bridge has reported Disconnected past the grace and cancels that venue's resting orders; a market that merely closed is disclosed FeedStatus::Stale, which never counts, so a close cannot reach it. The silence one (vike_core::DeadManConfig, deadman_timeout_ms, off unless the key is written) trips on ingest that has gone quiet on every venue at once and cancels everything — which is exactly why it may not be armed by default, a closed market being silence too. They share deadman_action, and under its default a trip also engages the halt. → The dead-man's switches.
• journal — the write-ahead command journal: pre-allocated mmap segments whose frames are [len][check][payload]; a record failing its check is a torn tail at which reading stops. → The command journal.
• emulated order — a conditional order, a fixed or trailing stop, held in the core's own ConditionalBook for a venue or strategy without native support. Arming bypasses the risk gate; the fire goes through the one live path as a plain market order, triggered by vike_model::order_fill_price, the same oracle the backtest fires on. Emulated and Released are the state machine's client-side conditional states. → Emulated orders.

Orders and reconciliation

• terminal — one of the five order states after which no further lifecycle event applies: Filled, Canceled, Rejected (the venue's refusal), Denied (the risk gate's veto, pre-venue) and Expired. OrderStatus::is_terminal names exactly those, and Liquidated is deliberately not among them. Every order must reach exactly one terminal, and a dead venue path must synthesize a terminal OrderRejected rather than let an order vanish. → Order lifecycle, Events.
• kind — the member name of a declared roster the runtime consults. A store kind is one kind= row of vike_data::store_kind::STORE_KINDS, the on-disk layout authority; an order kind is one of vike_model::venue_caps::ORDER_KINDS (market, limit, stop, stop_limit, take_profit, the last three the trigger kinds); a divergence kind is a DivergenceKind variant; a run kind is the one top-level manifest field a listing may branch on. → Data, Orders, Reconciliation, Runs on disk.
• divergence — one detected local-versus-venue disagreement, carrying the venue evidence needed to resolve it. vike_exec::recon::diff turns venue reports plus a LocalView into divergences; resolve turns those plus a ReconPolicy into a Recon — events to fold, a snapshot seed and alerts — and both are pure, with no I/O. → Reconciliation.
• held — a divergence a policy did not fold, kept as an operator alert awaiting confirm. A held divergence is a state, not an event: under quarantine one that nothing heals is re-diffed and re-held every pass, so the warning fires when it enters or leaves the held set and a re-raise refreshes its row rather than appending. → Policies.
• wiring class — how a venue's exec and reconcile sides are wired into a default live mount, the one docs-facing axis no capability table encodes because it is a property of make_engine's arms rather than of any adapter. Four classes: live-exec-recon, feature-gated (the arm compiles only under a vike-mount feature), sidecar-exec-no-recon (exec over an owned child process, no reconcile) and paper-only. crates/vike-ops/src/docs_data.rs's WIRING declares one named row per roster venue, gated for completeness, and ships in venues.json. → Venues, Reconciliation.

Data, venues and rules

• seam — a trait boundary two sides agree on without seeing each other. vike_exec::ExecutionClient is the one trait every venue bridge implements; HistStore is the unified historical-data seam, one store for bars and ticks; DataClient is its live mirror. → The ExecutionClient seam, The history store, The live data seam.
• bridge — a venue adapter: one crate per venue under crates/bridges/<venue>, built from vike-bridge-core's shared plumbing — blocking REST transport and signers, the venue-neutral WS user-data pump, the ExecActor command thread, credentials, the pinned Decimal wire-format site. → Venues.
• roster — vike_model::VENUES, the one canonical venue list: every per-venue capability table's completeness test iterates it, so adding a venue fails every table's tests until its rows exist, and a roster venue's row is always named even when its value equals the fallback. → Venues, Adding a venue.
• project — <project>, the one folder holding settings and credentials (<project>/settings/), program-written state (<project>/settings/state), runs and data. $VIKE_SETTINGS_DIR names the settings/ directory outright — <project> is derived from it — and wins over the walk up from the working directory; a blank value is ignored. The history store's own root follows one shared precedence — vike_model::store_path::resolve_store_root — in which anything stated outranks anything inferred. → Settings, The history store.
• parity fixture — the frozen golden files under fixtures/r0/ through fixtures/r6/ (there is no r2/), exported from the retired Python platform; every exporter was deleted, so the committed bytes are the oracle, and what the parity suites prove is that this code has not changed its arithmetic unnoticed. → The parity gate.
• gate — a CI test that holds a rule the way a paragraph cannot. crates/vike-ops/tests/layer_gate.rs turns "dependency direction: down only" into a merge gate over every manifest's declared layer, and most rules the concepts pages state are held the same way. → Architecture, Developer guide.