The target defines the outcome being learned

The Python project defines labels in its preparation functions. The Compiled project declares a target class with training construction and later transformation arguments. Both keep the outcome separate from the information available to the predictor.

Prerequisites

The matching wheel and recorded-input bundle supply both projects. The target diagnostics require the data and stats extras. Feature columns, their units, and their availability follow the decisions in feature design.

Outcome geometry determines the experiment

The 16 target classes cover six research purposes:

The target reference gives exact horizons, units, source-column exclusions, and unavailable-tail behavior. A class name alone does not establish the outcome's decision time.

Python labels preserve the next-bar meaning

The introductory Python experiment predicts next-bar open-to-close return. A negative shift attaches that later observed outcome to the current feature row:

1def prepare_split(bars, round_params):2    return features(bars, round_params["window"]).with_columns(3        (pl.col("close").shift(-1) / pl.col("open").shift(-1) - 1)4        .alias("next_return")5    ).slice(12).drop_nulls(["momentum", "next_return"])

Preparation executes separately within each chronological partition. Each partition loses its fixed warm-up and final unavailable label. The model receives momentum; next_return supplies the fitting outcome. Inference computes the feature without requiring a future label.

The validation backtest interprets the forecast through signed next-bar exposure and a declared round-trip cost. A different holding policy requires a corresponding comparison between the predicted outcome and the traded return.

Compiled target state fits on training observations

The introductory YAML experiment constructs its quantile target from training ROC values. The stored cutoff then transforms validation and test observations:

1    target:2      name: quantile_flag3      class: limen.targets.QuantileBinaryTarget4      fit_params:5        source_column: roc_16        quantile: 0.57      transform_params:8        shift: -1

The constructor receives fit_params, and each transformation receives transform_params. Parameter references can vary the target across candidates. That variation changes the research question as well as the labels used to evaluate it.

The separate Triple Barrier case sets volatility multiples of 1.5 and 1.0, a maximum horizon of three hourly observations, and an eight-observation volatility span. Its Ridge model treats the resulting ternary labels as numeric outcomes. The reported regression error measures that declared fit; interpreting a barrier class as a trade requires an explicit position mapping and policy.

1schema_version: '1.0'2metadata:3  name: target_triplebarrier4  mode: development5sfd:6  manifest:7    type: ml8    data_source:9      method: limen.data.HistoricalData.get_any_file10      params:11        file_path_or_url: inputs/spot_1h_20240101_20241231.parquet12    split_dates:13      train_start: '2024-01-01'14      train_end: '2024-02-15'15      val_start: '2024-02-15'16      val_end: '2024-03-15'17      test_start: '2024-03-15'18      test_end: '2024-04-15'19    indicators:20    - func: limen.indicators.roc21      params:22        period: 123        group: base24    - func: limen.indicators.returns25      params:26        group: base27    - func: limen.indicators.rolling_volatility28      params:29        column: returns30        window: 1231        group: base32    - func: limen.indicators.bollinger_bands33      params:34        group: base35    target:36      name: label37      class: limen.targets.TripleBarrierTarget38      fit_params:39        upper_multiple: 1.540        lower_multiple: 1.041        max_horizon: 342        span: 843        min_periods: 844    scaler:45      from_params: scaler_type46    reference_architecture: limen.sfd.reference_architecture.ridge_regressor47  params:48    scaler_type:49    - robust50    alpha:51    - 1.052    solver:53    - svd54uel:55  output_path: compiled-target-triplebarrier56  search_strategy:57    type: grid58  n_permutations: 159  prep_each_round: true60  output_format: csv61  recording:62    predictions: true63    alignment: true

Execution-derived outcomes retain their economics

TradeOutcomeTarget evaluates paired long and short opportunities through the shared execution engine. Fees, slippage, funding, price availability, and holding limits affect the resulting outcomes. Incomplete or unfilled opportunities remain unavailable. Direction/sizing models use completed paired outcomes and retain their learning and execution identities.

ExitQualityTarget requires supplied exit reason and net return. RiskRewardRatioTarget requires supplied capturable-breakout and drawdown values. The project diagnostics first verify rejection of missing context, then exercise explicitly identified software labels derived from recorded prices. Their provenance distinguishes those labels from observed venue exits.

The diagnostics preserve labeled and refused cases

The Python target campaign constructs each target on training observations, transforms the three chronological partitions, and retains labeled Parquet files. Its state checks require transformation to preserve fitted target state, apart from the declared random baseline. The volatility-normalized targets also enforce their training-volatility sanity gate.

The Compiled project executes the corresponding YAML target campaigns. Its result records both completed predictions and explicit training-gate refusals:

A refused target leaves no successful model result for that case. The report preserves that distinction alongside the admitted populations. Continue to model choice with the target meaning, label availability, and assessment population fixed.