Core concepts

One runtime model

fbtf uses one mental model for both historical backtesting and live paper trading.

That matters because strategy code tends to become harder to trust once backtest code and paper/live code drift apart. fbtf aims to keep the runtime model consistent enough that you do not have to mentally switch frameworks when moving between the two.

Bar-driven execution

The runtime is bar-driven in v1. Strategies react to completed bars rather than ticks.

This is a deliberate simplification. It keeps sequencing easier to reason about, keeps results easier to inspect, and avoids pretending the simulator is something more granular than it really is.

Deterministic behavior

The runtime aims to make runs reproducible and inspectable. That means explicit state transitions, explicit assumptions, and structured results.

In practice that means:

• feeds publish bars in a defined order
• runner state transitions are observable
• assumptions like slippage and commissions are explicit
• diagnostics are part of the public story, not hidden logs

Small root API

The root package stays intentionally small:

• defineStrategy
• createRunner
• createHistoricalFeed
• createLiveFeed
• createPaperBroker
• defineMarket

Everything else lives behind explicit subpaths like @thecommandcat/fbtf/data, @thecommandcat/fbtf/markets, and @thecommandcat/fbtf/experiment.

That split is intentional. The root package should stay readable. If everything becomes a front-door export, the library gets harder to learn and harder to evolve.

Adapter boundaries

Provider-specific logic belongs in adapters, not in the runtime core.

That is why data-loading helpers and Databento-specific behavior live in @thecommandcat/fbtf/data and @thecommandcat/fbtf/data/databento instead of being mixed into the runner itself.

Futures-first scope

The internal type model is asset-aware, but the practical product story is futures-first right now.

That means the docs and examples are opinionated about futures concepts like:

• tick size
• tick value
• contract quantity
• slippage and commission assumptions
• risk helpers that map naturally onto futures math

That is a scope decision, not an accident.

Where to go next

• read Runtime flow for the execution sequence
• read Data and markets for inputs and adapters
• read Results and diagnostics for outputs and observability