Runtime flow
How feeds, strategies, brokers, and the runner interact during execution.
Runtime flow
If you only remember one thing about fbtf, remember this: the runner is the coordinator, not the source of truth for everything.
The runtime is built from four main parts:
- market — defines the contract/tick assumptions for the run
- feed — provides bars in order
- strategy — produces intents based on the current context
- broker — applies those intents to paper-trading state
High-level sequence
For each bar:
- the feed advances to the next bar
- the runner builds the strategy context
- the strategy decides whether to emit an intent
- the broker updates paper state from the bar and any accepted order logic
- diagnostics, runtime events, and result snapshots are updated
The exact details differ a little between historical replay and live paper mode, but the mental model is the same.
Strategy context
Strategy code sees a context object rather than direct mutable runtime state.
That context includes things like:
- the current bar
- the bar index
- the current paper position/account view
- services (when configured)
- lifecycle/session metadata where relevant
The point is to keep strategy code explicit and testable.
Intents, not side effects
defineStrategy() is designed around returning intents like buy, sell, or close, not directly mutating the broker.
That keeps decision logic and execution logic separate.
Historical feed vs live feed
Historical
- finite replay
- deterministic ordering
- easier to reason about end-to-end
Live
- event-driven input
- duplicates/out-of-order behavior matters
- timeout and stale-decision behavior matters more
The integration tests in the repo are valuable here because they lock down the edge cases around live sequencing.
Broker role
The paper broker is responsible for:
- tracking orders
- tracking fills
- tracking trades
- maintaining account and position state
- applying slippage/commission assumptions
The runner should not duplicate those concerns.
Result assembly
After completion, the run result is assembled from the broker/account/diagnostic state into a structured result object.
That is what powers the result contracts and the experiment reporting layer.
Recommended mental model
Think about fbtf like this:
- feed answers: what bar are we on?
- strategy answers: what do we want to do?
- broker answers: what actually happened to paper state?
- runner answers: how do these pieces move in order?
fbtf docs
Deterministic backtesting and live paper trading docs for TypeScript.
Getting started
Install fbtf and run your first minimal backtest.
Core concepts
Understand the runtime model behind fbtf.
API overview
Learn the main entrypoints and useful subpaths.
Data and markets
Prepare inputs, define markets, and use adapter-based data loading.
Results and diagnostics
Inspect what happened after a run and understand how the runtime explains itself.
Experiments and CLI
Run experiment modules through the config-first fbtf CLI.
Roadmap
What FBTF is trying to finish next and what is intentionally out of scope.