Results and diagnostics

The output of a run matters as much as the ability to execute one.

fbtf treats results and diagnostics as part of the product surface, not just debugging leftovers.

Results

Use @thecommandcat/fbtf/results for the result contracts.

The main result story includes:

• run metadata
• summary metrics
• fills
• trades
• equity curve / account snapshots
• assumptions used during the run

That gives you enough structure to inspect what happened without scraping logs.

Why this matters

Backtesting gets untrustworthy quickly when the only answer to “what happened?” is a pile of console output.

Structured results let you answer:

• how many trades happened?
• what was realized vs unrealized PnL?
• what did slippage and commission assumptions do?
• what fills created each trade?

Diagnostics

Use @thecommandcat/fbtf/diagnostics when you need structured diagnostic events and recorders.

Diagnostics are useful for:

• invalid or stale decisions
• runtime warnings
• order-event tracing
• timing/external-call metadata

That makes them much more useful than ad hoc strings once strategies become more complex.

Recommended usage

• use result objects for reporting and analysis
• use diagnostics when you need to explain or debug runtime behavior
• keep both in mind when designing strategy flows, because observability is part of correctness in this kind of library

Related pages

• Core concepts
• Runtime flow
• API overview