Return datasets

You build a return dataset in its own Return Dataset tab, without running a full backtest. The tab carries the same position designer and entry/exit condition fields you use to define a trade, but it has no capital or sizing inputs. It is a structure-and-timing definition, nothing more. Once saved, it sits alongside the platform's pre-defined return datasets and is selectable everywhere they are.

What a return dataset is

A return dataset is a named, reusable timeline of outcomes for a fixed trade structure. Concretely: "what did a short ATM straddle opened every morning and closed at 3:45pm return, each day, over the past several years." One structure, one entry signal, one exit signal, replayed at every point in history where the entry signal fired.

The Return Dataset tab holds four things:

• Position designer. Define each leg exactly as you would for a trade: buy or sell, option type, expiry target, delta target. This is the same designer the entry, exit, and timing flow uses in a backtest.
• Entry condition. When the structure opens. For event-driven structures this is usually a calendar rule; for a daily structure it is a session-open timing rule.
• Exit condition. When the structure closes.
• Preview. A table of every qualifying historical entry and its return, so you can confirm the definition captures the events you meant before you save.

What the tab does not have is any notion of account size. There is no starting capital, no sizing mode, no margin configuration. A return dataset answers "what did this structure return per unit," not "what would it have done to a $50,000 account." Sizing and capital are the backtest's job.

What an outcome row contains

Each row is one qualifying historical trade. The engine that produces a backtest already computes exactly these fields for every closed position, so a return dataset is a named, saved wrapper around output the engine generates. The per-trade rows underneath it are what the backtest engine writes on every run.

One row holds:

There is one row per closed trade and nothing else. A return dataset does not carry an index column, a benchmark column, or a comparison series. It is the outcome of the structure, standing on its own. When a return dataset becomes a benchmark on a Signal tab, the comparison happens on the chart, not inside the dataset.

Defining a structure once and reusing it

The reason a return dataset is named and saved, rather than re-specified each time, is that one outcome definition feeds three different surfaces:

• As an EDA benchmark on many Signal tabs. Point several signals at the same return dataset and every one of them is read against the same trade outcomes, so their scatter and decile charts are comparable.
• As the target on a Model tab. A regression model trains to predict the return series the dataset holds.
• As the auto-fill for a backtest's position designer. When a backtest inherits a return-dataset benchmark from an earlier Signal or Model tab, its position designer and exit condition pre-populate from the dataset's definition. The structure you validated is the structure you backtest, with no re-typing and no chance of the two drifting apart.

Define the short ATM straddle once, and the same definition is the yardstick your signals are measured against, the thing your model predicts, and the starting point for the backtest that trades on the model's output.

Using a return dataset as an EDA benchmark

On a Signal tab, a return dataset is the outcome axis the EDA charts read your signal against. Two charts use it directly:

• Scatter. One dot per historical trade in the dataset. The X-axis is your signal's value at the moment that trade was entered; the Y-axis is that trade's return from the dataset. The dot cloud and its trend line answer whether the signal's reading at entry lines up with how the trade actually went.
• Decile. The same trades split into ten equal groups by signal value at entry, lowest to highest. Each bar is the mean of the dataset's returns for that group. A clean staircase across the deciles is the signal's predictive direction made visible.

Both charts pull their Y values straight from the return dataset's outcome rows. Change the dataset and every signal pointed at it is re-scored against the new outcomes.

Using a return dataset as a model target

The same outcome series a signal is scored against can be the thing a model predicts. On a Model tab, set a return dataset as the target and a regression model trains to predict the trade's return from your selected signals. The signals are the inputs; the return dataset is what the model is learning to forecast. A model that predicts a value (rather than a class) is the natural fit here, because a trade return is a value.

This is why the same short-straddle return dataset can serve the whole pipeline. It defines what "a good entry" means for EDA, and it defines what the model is trying to predict. One outcome definition, one meaning of success, carried end to end.

The outcomes carry backtest defaults

A return dataset inherits every fill assumption of the engine that produced its rows. The returns are only as honest as those assumptions, so read them before you trust a number.

The outcomes are computed under the run's fill mode: the Backtest.ai fill model (calibrated, and what paper and live always use), mid (an optimistic bound), or bid_ask (a pessimistic bound, buying at the ask and selling at the bid). Between trades, marks always use mid, whichever fill mode is set. A forced liquidation or equity-halt close always crosses the spread, even under mid fills, so a stressed run pays real spread cost on the way out whichever fill mode you chose. A mid-fill return dataset reads better than the same structure filled at bid/ask, so match the dataset's fill mode to the question you are asking before you compare a signal or train a model against it.