Research

Research in Vike Trader is a loop with four stations: a study asks a question of recorded data, a fit trains a model where the host can train one, a score turns the answer into numbers, and a run is what stays on disk afterwards, listed beside every backtest. All four live in one headless crate, vike-studio-core, whose crates/vike-studio-core/src/lib.rs header describes it as the Studio backend extracted from the GUI so headless consumers can reuse it without egui — the in-app AI loop is one, and the retired MCP server was another before its tool surface moved to vike-cli mcp. There is no GUI in it, which is why CI can test the whole loop.

The four stations

A study is a function called once with a context and a recipe, returning named numbers and named text artifacts. It comes in two tiers — interpreted Rhai and compiled Rust — and the lib.rs header records why the interpreted one lives here rather than beside its strategy twin: this is the only layer that can see both vike-script (the Rhai precedent) and vike-user-research (the study contract), because the lower crate may not name the higher. It also records the one property the interpreted tier has that the compiled one cannot: in a script, the sanctioned surface is enforcement.

A fit goes through the learner seam in vike-ml — Models — and the trainer is the upstream LightGBM binary driven as a child process, Training. The crate's own ml module is deliberately the inference half only: it loads a model somebody already trained from its text, scores rows into a probability series and reports which input mattered, and fits nothing. The platform fact behind that split is that the trainer binary is a Linux x86-64 executable and is not staged on any other host, while crates/vike-ml/src/infer.rs is pure Rust over the model text and works everywhere. So a study fits wherever it can fit, and Inference reads what came out.

A score is the study's own business. What the runner asserts about it is only the structurally true negative — crates/vike-studio-core/src/study_run.rs's STUDY_METRICS_NOTE says a study's numbers were produced by a study, not by the event-driven simulator, because vike-user-research declares no vike-backtest dependency, so no order book, queue position or fee schedule took part. That is why a study's metrics are never comparable with a backtest run's, and why the run format keeps them apart (below).

A run is minted by study_run — the header calls it what puts a study run there, and explains why the study crate cannot do it itself: run persistence lives above it in the layering, so a study returns a StudyOutcome and this crate, sitting above vike-backtest and already owning the listing those runs appear in, is the only one that can be the caller — crates/vike-studio-core/src/study_run.rs's header works through why the write order has to be what it is, down to what a half-written run would do to a listing. Running a study is that path end to end.

Where it all lives on disk

Everything user-authored sits under <project>/user_data/, and crates/vike-model/src/state_path.rs argues each directory. RESEARCH_SUBDIR files studies apart from strategies because a study is not a strategy: a strategy is a thing that is mounted, takes bars and emits orders; a study answers a question about data and produces a number, and nothing about it belongs in a list of things that can be armed. STUDIES_SUBDIR splits into the same two tiers a strategy has — the constants are RHAI_SUBDIR and RUST_SUBDIR themselves, not a second pair — so a user who knows where their .rhai strategies go has learned where their .rhai studies go.

RUNS_SUBDIR is deliberately at the user_data/ root, not under research/: a research run and a strategy backtest are the same shape — an id, a manifest naming the config, result files, a report — and the workflow this serves runs research and then a strategy on the same idea, so splitting them would file the two halves of one investigation in two places. Research owns the questions; runs/ owns every answer, of every kind. Studies covers the listing that reads it back.

The other pipeline in the crate

The same crate carries the Studio's Run pipeline — resolve a strategy, load a data slice from the history store, backtest, score — parameterised by two vocabularies the header names: StrategySpec (Rhai source or a native registry strategy plus params) and DataSlice (a venue, a symbol list and a SliceKind, either kind=bar series or the recorded quote/trade/book tick series replayed through vike_backtest::hist_replay). The run pipeline is that half, and Studio is the window over it. Where the strategies themselves come from is user_strategies — <project>/user_data/strategies/, which replaced the Studio's one-JSON-blob store — described under User strategies.

What a shipped build compiles

The crate declares layer 55 (crates/vike-studio-core/Cargo.toml), and its default build is DataFusion-free: lib.rs notes that the vike-study runner module is gated behind the study-cli feature precisely because a CI lane greps the crate's default normal-dependency tree for a datafusion crate and fails if it finds one — a structural check a compile-only test would pass. The concrete store is something a binary builds and hands down; nothing in this tree opens one on its own. vike-study is the binary that turns the feature on.

The rest of this section

• Studies — what a study is, where the two tiers live, and how runs and studies are listed with every failure named.
• Running a study — one entry point for both tiers, the order of operations, and what the manifest records.
• Rhai studies and Rust studies — the two tiers and their contract.
• The run pipeline — the Studio's resolve → backtest → score.
• Models, Training, Inference, The fit cache, Feature importance and Model pins — the model crate, end to end.
• Train a model walks a fitting study from recipe to run.