Lablrr: Feature Engineering, Done Right

Feature engineering is the single largest source of variance in any ML pipeline that touches financial time series. Every model — GARCH, VAR, transformer, deep RL policy network — depends on a feature matrix that someone, somewhere, decided was reasonable. That decision is almost always made by hand, almost always under-tested, and almost always the reason the model fails out of sample. Lablrr removes the hand-picking step entirely by composing three operations that already have rigorous foundations on their own: digital signal processing, exhaustive enumeration, and statistical labelling. The output is a Parquet feature matrix that requires zero manual engineering downstream.

The Problem Lablrr Solves

Anyone training a model on price data faces the same upstream choice: what goes into the observation vector? The conventional answer is "the indicators I happen to know about, at the parameters I happen to have heard of." This is the source of two compounding failures:

1. Indicator-parameter arbitrariness. RSI(14), MACD(12,26,9), Bollinger(20,2) were calibrated for daily commodity bars in the late 1970s. Their numerical defaults have no claim to optimality on any modern timeframe or instrument. Feeding them raw into a model means the model learns to exploit statistical artefacts of those specific parameter choices rather than the structure of the underlying price process.
2. Label leakage and label arbitrariness. "Up" and "down" over a fixed horizon are arbitrary labels. They throw away the conditional structure — regime, time of day, day of week, second-indicator state, excursion paths — that any sensible model would condition on if it had access to it.

The conventional response is to throw a larger model at the problem. That does not work. No architecture recovers information the feature matrix never contained.

Who Needs This

Four classes of consumers, all of whom currently spend most of their engineering time on a problem Lablrr eliminates:

Consumer	What they currently do	What Lablrr replaces
Deep RL teams (PPO, A3C, SAC)	Hand-pick indicators into the observation space at textbook defaults; agent overfits to parameter artefacts.	State vector becomes [OHLCV + top-N statistically validated signals + rolling stats], all pre-computed and pre-validated.
Transformer / LSTM / CNN researchers	Engineer features manually, retrain when defaults turn out to be wrong, ship anyway.	Architecture-agnostic tabular feature vectors with regime context, temporal metadata, excursion paths, and conformal bounds.
LLM wrappers and research copilots	Have the agent guess "reasonable" parameters; surface the guess as a recommendation.	The agent specifies asset + family; the feature matrix returned is already filtered to surviving configurations with audit metadata.
Autonomous research crawlers and swarm agents	Each node re-implements its own scrappy feature pipeline.	Single API call returns a structured Parquet file per asset; downstream consumers read columns by name.

The unifying property: all four consumers want to spend their time on modelling, not on the upstream question of what to put in the observation vector. Lablrr is the answer to that upstream question.

The Three Operations, Composed

1. Digital signal processing as the source of features

Every technical indicator on every chart is, in DSP terms, a FIR or IIR filter applied to the price series. Lablrr does not invent new indicators. It treats the full indicator family — RSI, MACD, Bollinger, ATR, Stochastic, plus DSP-native primitives like the Hilbert transform's analytic-signal triple (amplitude, phase, frequency) — as a parameterised filter bank. The filter parameters define a signal space: a high-dimensional lattice of every plausible filter configuration on the input series.

This is the only honest starting point. Any indicator default is a single point in a lattice that contains hundreds of thousands of equally-plausible neighbours.

2. Exhaustive enumeration across the signal space

Lablrr (driven by the Dojo engine) sweeps the full lattice. For a typical PermuCheck scan: RSI period ∈ {2..14000} × source ∈ {Close, HL2, OHLC4} crossed with MACD (fast, slow, signal) triples, on a 1-minute canonical axis spanning multiple years of bars. The result is millions of candidate signals, each with a complete per-bar time series of filter output.

Critically, the per-bar series is preserved, not aggregated away into a single summary statistic. This is what makes Lablrr possible: every column of the eventual Parquet matrix is the per-bar output of one filter configuration aligned to the original OHLCV timestamps.

3. Statistical labelling on the enumerated outputs

Enumerated signals are passed through the robustness gate cascade (walk-forward survival, permutation null with Benjamini-Hochberg FDR, concentration check, automatic out-of-sample split). Surviving configurations are then labelled per event with the conditional context any downstream model needs:

• regime_label — HMM- or PELT-detected market regime at the entry bar (low_vol, high_vol, trend, mean_reverting).
• direction — long or short, from indicator crossover direction.
• day_of_week, time_of_day — temporal metadata used as statistical gates and as features.
• third_indicator — conditional filter value at entry (a second indicator state, used for stratified gating).
• mfe, mae — maximum favourable and adverse excursion per event, stored as returns.
• conformal_interval — split-conformal prediction bounds with target coverage.
• breakeven_friction — per-event breakeven cost in basis points.
• signal_i — binary label per surviving configuration: did configuration i fire at this bar?
• win_rate_i, conv_time_i — column-level metadata recording the statistical evidence each configuration carries.

These labels are not editorial. Every one is derived from a defined statistical operation on the enumerated outputs, with the methodology stamped into the Parquet schema.

Output: A Parquet File That Is Already the Feature Matrix

For a PermuCheck scan of BTC-USDT with RSI × MACD across ~2,000 surviving configurations, the output schema is:

Column group	Example columns	Source
OHLCV	timestamp, open, high, low, close, volume	Original user data, time-aligned.
Per-bar indicator values	rsi_14, rsi_21, ..., macd_12_26_9, ...	DSP filter outputs, one column per configuration.
Signal labels	signal_847, signal_1203, ...	Binary fire/no-fire per configuration per bar.
Per-event labels	regime_label, direction, mfe, mae, conformal_interval, ...	Statistical labelling layer.
Per-config metadata	win_rate_847, conv_time_847 (column-level)	Robustness gate outputs.
Split metadata	Parquet partitioned as train/ and test/	Walk-forward / OOS boundary.

This file is the observation matrix. A PPO agent's env.reset() reads it, slices a column subset by name, and stops there. A transformer training script tokenises rows and stops there. No manual feature engineering, no manual labelling, no manual train/test split.

Why "Feature Engineering Done Right" Is Not Marketing

The phrase has three substantive components, each falsifiable:

Right inputs

Features come from a parameterised DSP filter bank, not from a list someone memorised. The full lattice is enumerated, not sampled.

Right filter on the inputs

Every configuration that reaches the output Parquet has passed walk-forward survival, permutation testing with multiple-testing correction, concentration analysis, and OOS validation. Configurations that overfit, that depend on a single lucky trade, or that fail to survive on later data are filtered out at the source.

Right labels alongside the inputs

The per-event labels (regime, time, direction, excursion, conformal bounds) are the conditional structure any sensible model would want to condition on. Most pipelines never compute these because computing them properly requires the per-bar indicator series, which conventional backtesters discard.

"Done right" is therefore a statement about the three composed operations producing a feature matrix that no single conventional step can produce.

Where Lablrr Sits in the Ecosystem

Adjacent tool	What it does	Where Lablrr is different
Tecton, Feast	Feature store — serves features your team already engineered.	Lablrr generates the features. The store assumes the engineering is done.
Scale AI, Labelbox	Human-in-the-loop labelling for CV and NLP datasets.	Lablrr labels financial time series with statistical operations, not human judgement.
QuantConnect, Alpaca	Algorithm execution platforms.	They execute. Lablrr produces the dataset their users would otherwise have to engineer by hand before they can train a model worth executing.
Numerai	Crowdsourced obfuscated features for a single tournament.	Lablrr: your private signals on your private data, no crowd, full schema transparency.

Where It Sits in the Student One Pipeline

Fetchrr → Loadrr → PermuCheck / Gemina → RunForward → Lablrr → export

Lablrr is the last mile. It does not compute new statistics; it repackages what the upstream engine has already computed — the per-bar indicator series, the surviving configurations, the gate decisions, the conformal bounds — into the Parquet schema described above. Available on the Pro plan and above as an export from the Results page.

Summary

Feature engineering for financial ML is broken in the same way at every shop that does it by hand: arbitrary indicator parameters, arbitrary labels, no validation that either choice generalises. Lablrr fixes this by composing three operations whose individual rigour is uncontroversial — DSP-derived filter banks as the feature source, exhaustive lattice enumeration to remove parameter arbitrariness, and statistical labelling to attach the conditional structure any sensible model needs to condition on. The output is a Parquet matrix that a DRL agent, a transformer, a GARCH-VAR, or a human analyst can consume without further preparation. That is what feature engineering done right actually looks like.