Concepts
How Vike Trader is put together — the crate layering, the single-writer core, the seam every venue implements, the order state machine, the gates in front of a live order, and the data the whole system shares.
The getting-started pages get you to a first backtest and a first paper mount without explaining why anything is shaped the way it is. This section is the explanation. Every page states a mechanism, names the code that is the authority for it, and says which test holds the invariant — because on this platform most of the rules below are gates in CI rather than sentences in a document, and a page that could not cite its claim was not written.
Reading order
The first eight pages build on each other and are best read in order:
- Architecture — a workspace whose dependency direction is machine-checked, and the one startup sequence every binary runs.
- The execution core — one thread owns all mutable trading state; everything reaches it through one ordered queue.
- The ExecutionClient seam — the single trait a venue bridge implements, and which of its methods are actually required.
- Order lifecycle — the state machine every order folds through, and the three rules a venue may not break.
- Risk and arming — the arming ceiling read before any credential, the credential gate behind it, the pre-trade gate on every order, and the halt.
- The data model — the value types every crate shares, and the interning rule that decides which fields may be a pointer.
- The history store — one Parquet store, thirteen declared layouts, and where it lives when nobody said.
- The three proofs: the paper exchange, the parity gate and the latency gate — what is checked bit-for-bit, and what is measured in microseconds.
The rest of the section
After that the pages stand alone, grouped by what they sit next to:
- Inside the core thread — the event bus, ingest lanes, timers, portfolio and snapshot, the control boundary, the watchdog, the dead-man's switches, emulated orders.
- Orders, money and stopping — the account, contingent orders, halt, margin calls, the price board.
- Mounting and startup — mounting, accounts, startup preflight, settings, the node protocol.
- Data in motion — the live data seam, the live mirror of the history store.
- Venue-free cores — options and alerting.
Several rosters these pages mention are documented one member per page in their own sub-trees, generated from the same CI-gated tables the runtime consults, so a page there cannot describe a capability the code no longer has: every event variant, every history store layout, every order kind, every asset class, and every reconciliation divergence kind. The command journal has a hand-written sub-tree of its own.
How to read a citation on these pages
A claim is cited by symbol — a repo-relative path plus a named identifier, joined by 's —
never by line number. crates/vike-exec/src/order.rs's ManagedOrder::apply means: open that
file, find that symbol, read its own documentation; it is the authority, and the page is the
summary. The form is chosen because line numbers rot silently — when the product tree's own
citation gate was written, 26 of its 33 line-number citations were already wrong, every one of
them exactly right on the day it was authored — and that gate now rejects a path:NNN citation
whose path resolves to exactly one file in the tree, deliberately leaving a shorthand path it
cannot resolve alone.
Glossary
The terms the concepts pages define — ceiling, mount, lane, fold, divergence, emulated order, terminal, wiring class, kind, run and their neighbours — one line each, with the symbol behind the word and a link to the page that defines it.
Architecture
A Cargo workspace whose dependency direction is down-only and machine-checked, and one startup sequence that every binary runs through the same owner.