Backtest Artifacts, Manifests, and Launch Contracts
CuteMarkets Team
Research
Backtest Artifacts, Manifests, and Launch Contracts
Backtest artifacts are the API between research and operations: they identify the experiment, preserve evidence, and freeze the paper-trading candidate.
Abstract
A trading research result is only useful if it can be recreated. That requires artifacts: profile manifests, pack manifests, selected trades, daily PnL, summaries, diagnostics, and launch contracts for paper validation.
Developers should think of these files as the API between research and operations.
Why Artifacts Matter
An equity curve is a summary, not an audit trail. It does not show what data was loaded, which contracts were eligible, why a trade was rejected, which fill model was used, or whether the strategy can be run again tomorrow. Artifacts answer those questions.
For options research, artifacts are even more important because the trade is the output of several fragile steps: signal timing, historical contract discovery, liquidity filtering, quote-aware fills, exits, and portfolio aggregation. If any of those steps changes, the result changes. A manifest tells the next developer what was actually tested.
Manifests Name The Experiment
A manifest records what was tested: strategy family, parameters, symbols, date range, geometry, pricing mode, and output expectations. Without a manifest, a result becomes dependent on memory and shell history.
Manifests are also useful for review. They make it possible to compare two research runs without reading every code path.
| Artifact | Purpose | Minimum fields |
|---|---|---|
| Profile manifest | Names the strategy and parameters. | Profile id, thresholds, DTE rules, fill policy, risk settings. |
| Data manifest | Describes the inputs used by the run. | Tickers, date range, endpoints, cache ids, coverage notes. |
| Trade log | Preserves filled and rejected decisions. | Signal timestamp, selected contract, entry/exit evidence, reject reason. |
| Daily PnL | Feeds portfolio metrics. | Date, gross PnL, net PnL, active symbols, drawdown. |
| Diagnostics | Explains whether the candidate passed gates. | Trade count, PBO, DSR, overlap, rejects, coverage. |
| Launch contract | Freezes the paper candidate. | Profile, symbol set, risk caps, execution policy, monitoring rules. |
The files do not have to be large. They have to be specific enough that another run can reproduce or challenge the conclusion.
Launch Contracts Freeze The Candidate
A launch contract is the paper-trading version of the research object. It should contain the selected profile, risk settings, symbol set, DTE rules, and execution controls needed by the bot.
If the launch contract cannot express the backtest, the strategy is not ready for paper. The gap should be fixed before orders are enabled.
For example, if the backtest selected calls with 1-3 DTE, max spread 12 percent of premium, and entry only after a completed bar, the launch contract should state those constraints. If the paper bot instead selects any weekly contract, allows wider spreads, or enters from provisional bars, the paper run is no longer testing the same object.
Artifacts Make No-Go Useful
No-go branches should still keep summaries and diagnostics. The next researcher needs to know whether the branch failed because of poor PnL, high PBO, low DSR, data coverage, execution rejects, or portfolio overlap.
This is how negative results become useful. A no-go branch with clean artifacts can prevent the team from rebuilding the same weak idea under a different name. It can also show which part was promising. Maybe the signal was reasonable, but the option expression was too illiquid. Maybe the model worked in one symbol but overlapped too much with an existing sleeve. Those are different lessons.
What A Review Should See
A reviewer should be able to answer these questions without rerunning the entire research stack:
- What profile was tested?
- Which data windows and endpoints were used?
- Which contracts were selected?
- Which trades were rejected and why?
- What fill policy priced entry and exit?
- Did the run pass trade count, drawdown, robustness, and overlap gates?
- What exact object would paper trading run?
If the answer is hidden in a notebook cell or a shell command, the research is not operational yet.
Example Launch Contract Fields
| Field | Why it matters |
|---|---|
profile_id | Connects paper trading to the promoted research row. |
symbol_universe | Prevents the bot from expanding into untested names. |
entry_window | Preserves the timing assumptions from replay. |
dte_policy | Keeps contract selection in the tested expiration regime. |
fill_policy | Carries quote-aware execution into paper. |
risk_budget | Defines sizing, daily loss caps, and max positions. |
reject_policy | Tells the bot when to fail closed. |
review_metrics | Defines what paper trading must report daily. |
Takeaway
Artifacts are not administrative overhead. They are how a developer turns a backtest into a repeatable research process and eventually into a paper-trading candidate. Start with a manifest, preserve selected trades and rejects, write daily PnL, and freeze only candidates that can be expressed as launch contracts.
FAQ
Related questions
What belongs in a launch contract?
A launch contract should freeze the selected profile, symbols, risk settings, DTE rules, execution controls, and any required data inputs.
Product links
Build the workflow with CuteMarkets
This article is part of the broader CuteMarkets product and research stack. Use the landing pages below to move from the blog into the specific API workflow you want to evaluate.
Backtesting Test Plan
Turn artifact expectations into causality, selection, execution, and portfolio tests.
Backtesting Framework
Use the framework spine for manifests, trade logs, diagnostics, and launch contracts.
Paper Trading Bot Operations
Carry artifacts into paper-trading checks, kill switches, and daily reviews.
Options Backtesting API
Connect research artifacts to historical contracts, quotes, trades, and aggregates.