Order-Flow Imbalance Features: Which Signals Predict Crypto/Equity Moves 1-5 Minutes Out?

Order-flow imbalance and its relatives are attractive candidates for short-horizon price features because several independent studies, across different asset classes and different time periods, report a relationship between imbalance in the limit order book and the direction or size of the next price move [2][4][6]. A secondary account reports that Cont et al. find a simple linear dependence between price changes and an indicator measuring imbalances between the order flow on the buy and sell sides of the LOB [3], which is consistent with these primary findings though not itself a primary result. This note collects what has actually been measured about these features, states clearly where the evidence stops, and gives a concrete build plan.

The practical stakes are that mid-price direction over the next few order book events is often too simple a target: Passage 644 states directly that predicting mid-price direction change for the next few events is too simplistic and not suitable for a practical trading strategy [1]. That is a caution against the simplest possible label design; it does not by itself specify what label or model family should replace it, so any move toward a different target (magnitude, waiting time, or a multi-horizon design) is our own inference, not something the claim states, and this inference is used later in the build steps when we recommend reporting waiting time and normalized price move as functions of the imbalance feature.

Finally, the question spans crypto and equities, and the cited studies are split by asset class: the LOB imbalance and price-jump studies are on Chinese equities [1], general limit order book queue dynamics [2][3], French CAC40 equities [4], Nasdaq equities [6], while a separate system integrates crypto (BTC) data streams for live inference [5].

Bid-ask imbalance at the top of the book is defined precisely in one of the cited papers: I=(qb-qa)/(qb+qa), where qb and qa are the bid and ask quantities posted at the top of the book [2, passage 649]. Positive imbalance indicates an order book heavier on the bid side, and negative imbalance indicates one heavier on the ask side [2, passage 649]. This is the simplest, cheapest version of the feature: one subtraction, one addition, one division, computed from a single LOB snapshot.

Multi-Level Order-Flow Imbalance, or MLOFI, generalizes this idea. MLOFI is described as a vector quantity that measures the net flow of buy and sell orders at different price levels in a limit order book [6]. Unlike the single-level imbalance I, MLOFI is a vector, so it carries information from several depth levels simultaneously rather than compressing everything into one ratio at the best bid and ask.

Trade-flow and liquidity features form a third family. One paper defines a price jump precisely as a sell (buy) market order arrival executed at a price smaller (larger) than the best bid (best ask) price immediately after the preceding market order arrival [4, passage 661]. That same paper extracts features from limit order volumes, limit order price gaps, market order information, and limit order event information [4, passage 661], which is a broader feature set than imbalance alone: it includes trade sign and size, not only resting liquidity. Passage 661 separately states that liquidity balance on best bid and best ask is quite informative for predicting the future market order's direction [4], which is a different prediction target than the price jump itself.

A separate strand of work treats the LOB and trading process as a joint stochastic system rather than a static snapshot. One paper studies the probability of price movements and trade arrivals as a function of the quote imbalance at the top of the limit order book, and proposes a stochastic model to capture the joint dynamics of the top-of-book queues and the trading process [2, passage 647]. Separately, passage 653 reports, as a secondary account of Cont et al.'s result rather than as its own primary finding, that Cont et al. find a simple linear dependence between price changes and an indicator measuring imbalances between the order flow on the buy and sell sides of the LOB [3, passage 653], which is consistent in spirit with the imbalance-based approach, though it is a separate study and not a joint benchmark against the others.

The mechanism reported for top-of-book imbalance is expressed through two quantities: the average mid price move normalized by the bid-ask spread, and the waiting time until the next mid price move, both studied as functions of book imbalance [2, passage 646]. This gives a builder two outputs to target, not one: a magnitude (normalized move) and a timing (waiting time), both indexed by the same imbalance input.

For an order posted at the bid side, the relevant stopping time is the time of first arrival of a sell trade, and for an order posted at the ask side, it is the time of first arrival of a buy trade [2, passage 651]. This is a precise, event-driven definition, useful for anyone who wants to reproduce the waiting-time calculation rather than approximate it with fixed clock time.

The size of the effect is bounded. In the case shown, the average price move can be up to a third of the spread in a highly imbalanced book [2, passage 646], and more generally the price change until the next tick is well approximated by a linear function of the imbalance and is typically well below the bid-ask spread, even for highly imbalanced order books [2, passage 650]. A high book imbalance is, on average, a good predictor of mid price movements [2, passage 650], and highly imbalanced books indicate that a price move is likely to come in a relatively short time [2, passage 650]. But the same paper is explicit that this does not translate into a trading edge by itself: although book imbalance may be used as a predictor for the next price movement, it does not by itself offer an opportunity for a straightforward statistical arbitrage [2, passage 650]. This is an important caveat for anyone tempted to trade the raw signal directly.

Underlying all of this is a statement about the data: the data display the non-martingale nature of prices at the short time scales considered [2, passage 646]. That is the empirical basis for expecting any short-horizon predictability at all in this line of work; it is a property of the studied data, not a universal law, and it comes from this specific study.

The CAC40 price-jump study builds a feature set wider than imbalance alone. It extracts features from limit order volumes, limit order price gaps, market order information, and limit order event information [4, passage 661], and it applies logistic regression to predict the price jump from limit order book features [4, passage 661]. To handle the number of candidate features, it introduces LASSO logistic regression to perform variable selection and highlight the importance of different features in predicting the future price jump [4, passage 661]. LASSO gives an interpretable ranking: which features survive shrinkage and which do not.

The result of that variable selection, based on forty largest French stocks of CAC40, is that trade sign and market order size as well as liquidity on the best bid and best ask are consistently informative for predicting the incoming price jump [4, passage 661]. This is a direct, named answer to which features matter most in that equity setting: trade sign, market order size, and top-of-book liquidity, retained by LASSO shrinkage rather than picked by hand [4, passage 661].

Several concrete numbers appear across these papers, each tied to its own benchmark and asset class. The China-market LOB benchmark covers a few thousand stocks from June to September 2020 [1], and its protocol forecasts the upcoming volume-weighted average price change and volume at the end of every second over 12 horizons ranging from 1 second to 300 seconds [1]. Within that protocol, results based on a linear regression model and deep learning models are compared [1], and the same paper proposes a more practically effective set of features to capture both LOB snapshots and periodic data [1]. This is the only claim set here that directly compares a linear model against deep learning models on a stated benchmark [1]; the comparison establishes that the two model families were tested head-to-head, but the claims do not state which one achieved better performance, so a reader cannot know from this evidence whether linear or deep learning won.

For MLOFI, the measured result is a goodness-of-fit comparison across depth levels, not across feature families. Using data for 6 liquid stocks on Nasdaq, the paper fits a linear relationship between MLOFI and the contemporaneous change in mid-price [6], and for all 6 stocks studied, the out-of-sample goodness-of-fit improves with each additional price level included in the MLOFI vector [6]. This is a within-feature comparison (level 1 versus level 2 versus deeper levels of the same MLOFI construction), not a comparison of MLOFI against trade-flow or against single-level imbalance I.

The conditions behind the CAC40 result are specific and are set out once, in the implementation notes section below: the dataset window, the millisecond recording, the visible depth of five levels, the restriction to 09h05 to 17h25, and the separate morning and afternoon datasets [4].

For the top-of-book imbalance study, the measured quantities are the normalized average price move and the waiting time as functions of I, with the one specific reported figure being that the average price move can be up to a third of the spread in a highly imbalanced book [2, passage 646]. There is no accuracy, precision, or R-squared number attached to this claim in the source; it is a magnitude statement about price moves, not a model-evaluation statistic. Taken together, the measured evidence answers narrower questions than the one asked here: how many depth levels to include in an MLOFI vector [6], which features survive LASSO selection on CAC40 stocks [4], how large the next price move is relative to the spread [2, passage 646], and how a linear model compares with deep learning models on a second-scale Chinese benchmark [1].

A builder reproducing any of these feature families needs to know the exact data each study used, because sampling frequency and depth differ sharply. The CAC40 price-jump study uses a dataset comprising trades and limit order activities of the 40 member stocks of the CAC40 between April 1st 2011 and April 30th 2011 [4], with every transaction and every limit order book modification recorded in milliseconds [4]. It uses a visible depth of five levels, with L=5 [4], and, to avoid open and close hours, the data are restricted to 09h05 to 17h25 [4]. It also explicitly neglects stop orders and iceberg orders because they are relatively rare compared with limit order and market order events [4], and, to remove intraday seasonality, the analysis is based on separate morning and afternoon datasets [4]. Each of these is a concrete preprocessing decision a builder should copy or consciously deviate from.

The China-market benchmark dataset spans a few thousand stocks over June to September 2020 [1], with second-level labels over 12 horizons from 1 to 300 seconds [1]. This is a much coarser time granularity than millisecond LOB modifications, so it suits second-scale rather than tick-scale feature engineering.

The Nasdaq MLOFI study works from 6 liquid stocks [6], a small, hand-picked sample chosen for liquidity, not a broad universe; a builder generalizing MLOFI to a new universe of assets should treat the reported improvement in out-of-sample fit with each added price level [6] as a hypothesis to re-test on their own data, not as a property already established beyond those 6 stocks.

One recent system described in the sources is explicitly built for real-time deployment rather than offline study, and is a useful architectural reference even though it was not tested here against the imbalance features above. The system integrates historical datasets (FI-2010, LOBSTER, BTC) with live WebSocket-based market feeds, a modular preprocessing engine, and multiple deep learning architectures for real-time limit order book forecasting [5]. Its preprocessing normalizes incoming order book snapshots using Z-score and Batch-Instance Normalization (BiN) [5], and it extracts multi-level price and volume features and generates multi-horizon movement labels [5], which is conceptually aligned with the multi-level and multi-horizon designs used in the imbalance literature above, though it is a separate engineering paper, not a feature-comparison study.

The models named are MLPLOB, TLOB, DeepLOB, and BinCTABL, trained on preprocessed data and served through a FastAPI backend [5]. For live inference, a frontend streams real-time exchange data such as Binance via WebSockets, and the backend processes this data to produce instant predictions [5]. Because this pipeline handles crypto data (BTC) directly, it is the one part of this evidence base that touches production-style crypto inference, though it does not report a feature-family comparison of OFI versus depth imbalance versus trade-flow on that data.

Usefully for a builder who wants to compare feature sets or model families honestly, the system allows multiple models can be loaded concurrently but their predictions are returned independently to enable transparent comparison [5]. That design, running several models side by side and reporting each output separately rather than an ensemble average, is exactly the pattern needed to run a fair walk-forward comparison between OFI-based, MLOFI-based, and trade-flow-based feature sets without one masking the other's error profile.

None of this is CPU-only by construction: on our own reading, and not as a sourced claim, DeepLOB, TLOB and similar architectures are typically GPU-trained deep networks. For a CPU-only production target like sam, this system is best read as an architecture pattern (multi-model, independent serving, live WebSocket ingestion) to imitate with cheap linear or logistic models substituted for the deep networks, rather than as a system to deploy unchanged.

As stated in the direct answer above, this evidence base contains no head-to-head test of OFI, multi-level depth imbalance, and trade-flow feature sets on the same data under purged, embargoed walk-forward cross-validation, and none of it is run jointly across three named crypto exchanges and equities. The China-market study compares linear regression against deep learning models on second-scale volume-weighted price and volume targets [1], but does not isolate OFI versus depth imbalance versus trade-flow as separate inputs. The MLOFI study reports that fit improves with depth on 6 Nasdaq stocks [6], but does not compare MLOFI against trade-flow features. The CAC40 study selects trade sign, order size, and top-of-book liquidity as consistently informative [4], but this is a within-model variable-selection result, not an out-of-sample cross-validated comparison against a separately defined depth-imbalance model. The top-of-book imbalance study establishes a predictive relationship and explicitly warns it is not a standalone arbitrage opportunity [2], which is a strong caution against overselling any imbalance-only strategy.

A second limit is asset-class coverage. The imbalance, MLOFI and price-jump studies are all on equities (Chinese stocks [1], Nasdaq stocks [6], CAC40 stocks [4]); the only crypto-touching system here is the live deployment architecture [5], which does not report a feature comparison. Applying equity-derived feature rankings to crypto order books, across three exchanges, is therefore an extrapolation the evidence does not support; it must be tested, not assumed.

A third limit is that none of the cited claims mention purged or embargoed walk-forward cross-validation as their evaluation protocol. The China benchmark uses a stated horizon structure [1], the CAC40 study uses morning/afternoon split data [4], and the imbalance papers report population-average relationships without a stated train/test split protocol at all [2][3]. A builder who needs purged, embargoed walk-forward validation for a production model must impose that protocol themselves; it is not already present in any cited method.

Finally, the label-design caution discussed in the introduction comes from only one study [1]. Given this, the practical response is to build the feature pipeline described here, but to evaluate it with the stricter protocol the question demands, on the builder's own crypto and equity data, before drawing any comparative conclusion.

Claim-grounded build steps (each grounded in a cited passage):

1. Ingest LOB snapshots first. Every step below requires a working limit order book snapshot feed, since the features defined in the cited claims operate on top-of-book and multi-level book quantities, not on OHLCV bars alone.
2. Collect LOB snapshots for each target exchange or equity series. Keep several depth levels per snapshot; for reference, the CAC40 study used a visible depth of five levels, with L=5 [4], and out-of-sample fit improved with each additional price level included in the MLOFI vector on the 6 Nasdaq stocks studied [6].
3. Compute the single-level imbalance I=(qb-qa)/(qb+qa) from best bid quantity qb and best ask quantity qa, following the definition of that formula over top-of-book posted quantities [2]. Store its sign (positive means bid-heavy, negative means ask-heavy) [2] as a baseline feature.
4. Build the MLOFI vector by extending the imbalance idea to net order flow at multiple price levels rather than a single-level snapshot ratio, following the definition of MLOFI as a vector quantity measuring net flow of buy and sell orders at different price levels [6]. Keep at least as many levels as your LOB snapshot depth allows, since fit improved with each added level in the cited equity study [6].
5. Build the trade-flow feature set separately: limit order volumes, limit order price gaps, market order information, and limit order event information [4], including trade sign and market order size [4] and liquidity on best bid and best ask [4]. Exclude stop orders and iceberg orders from this feature construction if they are rare in your data, following the CAC40 study's rationale [4].
6. If you want a directional (jump/no-jump) label, define it exactly as the CAC40 study does: a sell (buy) market order arrival executed at a price smaller (larger) than the best bid (best ask) price immediately after the preceding market order arrival [4].
7. Split intraday data by session half (morning/afternoon or equivalent) to control intraday seasonality before fitting, as done in the CAC40 study [4], and restrict away from open/close hours if your exchange has analogous edge effects, following the same paper's 09h05-17h25 restriction rationale [4].
8. Fit two baseline models per feature family: a linear regression for a magnitude target (following the linear model used as one baseline in the China benchmark comparison [1] and the linear fit used for MLOFI against mid-price change [6]) and a logistic regression, optionally with LASSO variable selection, for a directional/jump target (following the CAC40 study's method [4]).
9. Evaluate a waiting-time component using the stopping-time definition given in the imbalance study: for an order at the bid, the first arrival of a sell trade; for an order at the ask, the first arrival of a buy trade [2]. Report waiting time and normalized price move as functions of the imbalance feature (this step is based on our own inference from the label-design caution [1], not a direct instruction from that claim), mirroring the reported result that a highly imbalanced book indicates a price move is likely to come soon [2].
10. Do not treat a predictive-fit number as a strategy: the source evidence explicitly states that book imbalance, even when predictive, does not by itself offer an opportunity for a straightforward statistical arbitrage [2].

Author's own inference, not stated by any cited claim: the passage criticizing single-tick mid-price direction labels [1] states that such a label is too simplistic for a practical trading strategy, but it does not prescribe a replacement. On our own reasoning, a builder might instead consider a label at a 1-to-5 minute horizon, or the two-output design mirroring what was measured for top-of-book imbalance (normalized average price move, and waiting time until the next mid price move) [2], rather than defaulting to a single-tick direction label. This recommendation is ours, not the claim's.

Comparing feature families against each other (imbalance versus MLOFI versus trade-flow, on the same data, under a purged, embargoed walk-forward protocol) is not something any cited claim already does; see the direct answer above for that caveat, stated once.

Appendix: illustrative harness code, the author's own construction, not grounded in any cited claim. None of the concrete engineering below (the StandardScaler step, the purged/embargo walk-forward splitter, the LASSO logistic configuration, the quantile band construction) is specified by any claim in this note; the claims supply only the feature definitions and the model families, not this implementation. It is included as an illustrative pipeline harness.

It is also not an implementation of the build steps above. The methods cited here operate on limit order book snapshots: the single-level imbalance I=(qb-qa)/(qb+qa) is defined over posted bid and ask quantities at the top of the book [2, passage 649], and MLOFI is defined over net order flow at several depth levels [6]. Our bars table holds only OHLCV data and contains no LOB table, so the features below are OHLCV-only proxies that share the shape of those features but not their inputs. Because of that, the build steps in the section above require a separate LOB-snapshot ingestion step before claim-grounded feature code can be written; this appendix script exercises the surrounding machinery (feature assembly, per-family fits for imbalance-only, MLOFI-only, trade-flow-only and combined feature sets, walk-forward evaluation, forecast writing) so that the harness is ready the moment a real LOB reader is added.

No executable implementation grounded in the cited claims can be provided from the given claims and data. The methods described in this note require limit order book snapshots as input: the single-level imbalance I=(qb-qa)/(qb+qa) is defined over posted bid and ask quantities at the top of the book [2, passage 649], MLOFI is a vector quantity over net order flow at different price levels in the book [6], and the trade-flow features are extracted from limit order volumes, limit order price gaps, market order information, and limit order event information [4, passage 661]. The available tables for code execution (bars, forecasts, trades, book) do not establish that limit order book snapshots in the form these claims require are present: bars is an OHLCV table, and an OHLCV-derived proxy for imbalance, MLOFI, or trade-flow would not be testing the cited claims, only imitating their shape on unrelated input data. Rather than present code that appears to implement the cited methods while actually running on different, unverified data, this section states plainly that no such implementation can be built without first confirming that the book table (or an equivalent LOB snapshot source) contains top-of-book and multi-level bid/ask quantities as the claims define them, plus a specification of how those snapshots align in time with the trades and bars tables. None of that is established in the claims provided.

The script reads one-minute bars for all symbols in the database from bars(symbol, tf, ts, open, high, low, close, volume)builds the proxy features, fits a linear regression to predict the next-bar return and an L1-penalized logistic regression to predict the sign of the next move, fits and evaluates each feature family separately (imbalance-only, MLOFI-only, trade-flow-only) as well as the combined set under the author's own purged, embargoed walk-forward split, and writes q10/q50/q90/p_up forecasts into the forecasts table. The horizon is a parameter the user sets at the top of main() (HORIZON), anywhere in the 1-to-5 minute window; no cited claim picks a specific value inside that window, so the choice is left to the caller. Each forecast row is stamped with made_atwhich records the timestamp of the bar from which the forecast was made (the bar's own ts field), not the wall-clock time the script was executed; this allows the forecast table to map each prediction back to the exact market snapshot it was generated from. The baseline to beat is a naive persistence model (predict zero return, predict p_up=0.5); the number to check is out-of-sample R-squared for the linear model and out-of-sample accuracy for the logistic model, both against that naive baseline.

""" Illustrative harness: OFI-style feature pipeline and CPU-only baselines on OHLCV bars.
This script is the author's own construction. No cited claim specifies the
scaling, cross-validation splitter, solver settings or quantile band used here.
Runs fully offline (no network). Python 3.12, numpy, pandas, scikit-learn, sqlite3.

The script expects bars(symbol, tf, ts, open, high, low, close, volume) and
forecasts(symbol, horizon, made_at, q10, q50, q90, p_up) tables to exist in
data.sqlite.

IMPORTANT: this schema has no limit-order-book snapshot table, so this script
CANNOT test the cited claims. The single-level imbalance I = (qb - qa)/(qb + qa)
[2, passage 649] and MLOFI over depth levels [6] both require book-level
quantities we do not have here. The "imbalance", "MLOFI" and "trade-flow"
features below are OHLCV-only proxies that reproduce the *shape* of those
feature families, not their inputs:
  - single-level imbalance proxy, shaped after I = (qb - qa) / (qb + qa)   [2, passage 649]
  - MLOFI proxy, a vector over pseudo-levels, shaped after MLOFI          [6]
  - trade-flow / signed volume proxy, shaped after the CAC40 feature set  [4]
A real LOB-snapshot ingestion step must be added before the build steps in
"How to build it" can be implemented against this harness.
"""

import sqlite3
import numpy as np
import pandas as pd
from sklearn.linear_model import LinearRegression, LogisticRegression
from sklearn.preprocessing import StandardScaler

DB_PATH = "data.sqlite"

# User-set parameters. HORIZON is the forecast horizon in minutes; any value in
# the 1-to-5 minute window is valid and no cited claim prefers one over another,
# so the caller picks it. EMBARGO is our own cross-validation choice (see
# purged_embargo_walk_forward_splits).
HORIZON = 3
EMBARGO = 5


def list_symbols(conn, tf="1m"):
    # Returns every symbol that has bars at the given timeframe.
    q = "SELECT DISTINCT symbol FROM bars WHERE tf = ? ORDER BY symbol ASC"
    return [r[0] for r in conn.execute(q, (tf,)).fetchall()]


def load_bars(conn, symbol, tf="1m"):
    # Reads one symbol's bars, ordered by timestamp. Input: sqlite3 connection,
    # symbol string, timeframe string. Output: pandas DataFrame.
    q = """
        SELECT symbol, tf, ts, open, high, low, close, volume
        FROM bars WHERE symbol = ? AND tf = ? ORDER BY ts ASC
    """
    df = pd.read_sql_query(q, conn, params=(symbol, tf))
    return df


def build_single_level_imbalance_proxy(df):
    # Proxy only. The real feature is I = (qb - qa) / (qb + qa), defined over
    # top-of-book bid and ask quantities [2, passage 649], which this schema
    # does not store. We build a directional pressure proxy from the bar itself:
    # how close the close is to the high (buy pressure) versus the low (sell pressure).
    rng = (df["high"] - df["low"]).replace(0, np.nan)
    buy_pressure = (df["close"] - df["low"]) / rng
    sell_pressure = (df["high"] - df["close"]) / rng
    imbalance = (buy_pressure - sell_pressure).fillna(0.0)
    return imbalance


def build_mlofi_proxy(df, levels=(1, 2, 3, 5)):
    # Proxy only. Real MLOFI is a vector of net order flow across depth levels
    # of the book [6]. With OHLCV alone we build lagged/smoothed versions of the
    # single-level proxy so the model receives a vector of related signals,
    # matching the vector shape of MLOFI but not its book-level definition.
    base = build_single_level_imbalance_proxy(df)
    out = {}
    for lvl in levels:
        out[f"mlofi_l{lvl}"] = base.rolling(lvl, min_periods=1).mean()
    return pd.DataFrame(out)


def build_trade_flow_features(df):
    # Proxy for the trade-flow family found consistently informative on CAC40:
    # trade sign and market order size [4]. Signed volume: sign of the bar
    # return times the bar volume.
    ret = df["close"].pct_change().fillna(0.0)
    sign = np.sign(ret)
    signed_volume = sign * df["volume"]
    trade_intensity = df["volume"].rolling(5, min_periods=1).mean()
    return pd.DataFrame({
        "signed_volume": signed_volume,
        "trade_intensity": trade_intensity,
    })


def build_feature_matrix(df, horizon):
    # Assembles the full feature set and the two targets:
    #   y_ret: forward return over `horizon` bars (regression target)
    #   y_dir: sign of forward return (classification target)
    # `horizon` is explicit (no default) so the 1-to-5 minute target range is
    # always a deliberate choice at the call site.
    imb = build_single_level_imbalance_proxy(df).rename("imbalance")
    mlofi = build_mlofi_proxy(df)
    tf = build_trade_flow_features(df)
    feats = pd.concat([imb, mlofi, tf], axis=1)

    fwd_close = df["close"].shift(-horizon)
    y_ret = (fwd_close / df["close"] - 1.0)
    y_dir = (y_ret > 0).astype(int)

    data = pd.concat(
        [df["ts"], feats, y_ret.rename("y_ret"), y_dir.rename("y_dir")], axis=1
    )
    # Drop rows with missing target labels (forward returns that fall off the
    # end of the series). This determines which rows are used for training.
    data = data.dropna().reset_index(drop=True)
    return data


def feature_families(feature_cols):
    # Splits the combined feature set into the three families the note compares,
    # so each can be fitted and scored on its own as well as together.
    imbalance = [c for c in feature_cols if c == "imbalance"]
    mlofi = [c for c in feature_cols if c.startswith("mlofi_")]
    trade = [c for c in feature_cols if c in ("signed_volume", "trade_intensity")]
    return {
        "imbalance-only": imbalance,
        "mlofi-only": mlofi,
        "trade-flow-only": trade,
        "combined": list(feature_cols),
    }


def purged_embargo_walk_forward_splits(n, n_splits=5, horizon=HORIZON, embargo=EMBARGO):
    # Author's own purged, embargoed walk-forward split. Expanding train window,
    # a test block after it, and purging of rows within `horizon` bars of the
    # test start (because forward-looking labels from those rows overlap with
    # the test set), plus an embargo gap between the purge cutoff and test start
    # to simulate real-time deployment latency. This splitter removes all training
    # rows within `horizon` bars of the test period, implementing true purging
    # as well as an embargo; the horizon and embargo values are our own choice.
    fold_size = n // (n_splits + 1)
    splits = []
    for i in range(1, n_splits + 1):
        test_start = fold_size * (i + 1)
        test_end = min(test_start + fold_size, n)
        if test_start >= test_end:
            continue
        # Purge: remove training rows within `horizon` of test_start (their labels
        # reach into the test period). Embargo: add a further gap of `embargo` bars.
        purge_cutoff = test_start - horizon - embargo
        if purge_cutoff  0 else 0.0
    acc_naive = max(y_dir_test.mean(), 1 - y_dir_test.mean())
    return r2_naive, acc_naive


def make_lasso_logistic():
    # L1-penalized (LASSO) logistic regression. Passage 661 states that LASSO
    # logistic regression is used for variable selection over LOB features [4],
    # but it does not specify the solver, l1_ratio or max_iter, so these
    # hyperparameters are our own choice.
    return LogisticRegression(penalty="l1", solver="saga", l1_ratio=1, max_iter=1000)


def fit_and_evaluate(data, feature_cols, horizon):
    # Two model choices, each mapped to a specific claim:
    #  - Linear regression on the return target mirrors the linear regression
    #    model that is compared against deep learning models on the Chinese
    #    stock market LOB benchmark [1], and the linear relationship
    #    fitted between MLOFI and the contemporaneous mid-price change on 6
    #    Nasdaq stocks [6].
    #  - LASSO logistic regression on the direction target mirrors the LASSO
    #    logistic regression used to predict price jumps and to perform
    #    variable selection over LOB features on CAC40 stocks [4]; the solver,
    #    l1_ratio and max_iter settings are our own choice, not stated in that claim.
    # StandardScaler normalization is our own choice; claim [5] mentions Z-score
    # and Batch-Instance Normalization for a different system, but StandardScaler
    # is neither of those and is explicitly flagged here as an author's addition.
    n = len(data)
    splits = purged_embargo_walk_forward_splits(n, n_splits=5, horizon=horizon, embargo=EMBARGO)

    lin_r2s, log_accs = [], []
    lin = log = scaler = None
    for train_idx, test_idx in splits:
        train = data.iloc[train_idx]
        test = data.iloc[test_idx]

        scaler = StandardScaler()  # author's own normalization choice
        X_train = scaler.fit_transform(train[feature_cols])
        X_test = scaler.transform(test[feature_cols])

        # Linear regression on forward return: the linear baseline compared
        # against deep learning models on the China benchmark [1], and the
        # linear MLOFI-vs-mid-price-change fit [6].
        lin = LinearRegression()
        lin.fit(X_train, train["y_ret"])
        pred_ret = lin.predict(X_test)
        ss_res = np.sum((test["y_ret"] - pred_ret) ** 2)
        ss_tot = np.sum((test["y_ret"] - test["y_ret"].mean()) ** 2)
        r2 = 1 - ss_res / ss_tot if ss_tot > 0 else 0.0
        lin_r2s.append(r2)

        # LASSO-style logistic regression on direction: the LASSO logistic
        # variable-selection method applied to price-jump prediction on
        # CAC40 limit order book features [4], with our own solver, l1_ratio
        # and max_iter settings.
        if train["y_dir"].nunique()  r2_naive)
    print(f"[{symbol}] model beats baseline on accuracy:", acc > acc_naive)

    write_forecasts(conn, symbol, horizon, lin, log, scaler, feature_cols, data)


def main():
    conn = sqlite3.connect(DB_PATH)
    horizon = HORIZON  # minutes ahead; user-set parameter, any value in the 1-to-5 minute window

    symbols = list_symbols(conn, tf="1m")
    if not symbols:
        print("No symbols with 1m bars found.")
        conn.close()
        return
    print("Symbols found:", symbols)

    for symbol in symbols:
        run_symbol(conn, symbol, horizon)

    conn.close()


if __name__ == "__main__":
    main()