A Strategy Factory for CME Futures

The thesis

Most people accept randomness as a foundational property of financial markets. Lydon Quantitative began from the opposite premise, the one stated on the research page of this site: what looks random is unmeasured structure, and the work is to find the pieces of the puzzle, place them, and watch the picture sharpen.

In practice that premise became a library. Nine branches of pure and applied mathematics, from information geometry and optimal transport to persistent homology and rough-path signatures, were implemented as functions of bar data. Each was then held to the same question: does its output, measured honestly, predict anything the execution engine can actually be paid for?

The second half of that question is the part that distinguishes the system. LQ’s central commitment was never to a particular signal. It was that every signal, however elegant, had to earn its place through one measurement protocol, and that the protocol rather than the operator decided what traded tomorrow.

The problem that shaped the design

The platform was built to trade proprietary-firm evaluation accounts in CME futures. The arrangement is simple to state. A firm sells an evaluation: trade a simulated account under its rules, and if you reach a profit target before breaching a trailing maximum loss, you are given a funded account and keep most of what it earns. The rules are precise and published. For the 50K programs the system was designed against, a profit target of $3,000, a trailing maximum loss of $2,000 measured at end of day, a consistency rule forbidding any single day from exceeding half of total profit, a minimum number of qualifying profitable days, a flat-by-close requirement, position caps, and a ban on hedging across accounts.

This reframes the research problem. The objective is not maximum risk-adjusted return. It is the shape of a daily profit-and-loss distribution relative to a barrier geometry: a race to one line before touching another, under a cap on any single day’s contribution. A system with higher expectancy but higher variance can be a worse answer than a modest one with bounded, symmetric days. Section 3 formalizes this; the consequences run through every later design choice, from the measurement target to the fixed-size bracket.

A factory, not a strategy

The project’s own description of itself was a five-stage pipeline that produces a new deployable strategy bundle every night: enumerate what is measurable, score every candidate against reality, select survivors per instrument, combine across instruments, and trade tomorrow’s session atomically. The strategy that runs tomorrow is emergent from tonight’s data. Nothing is hard-coded; everything is selected. The “strategy” is the algorithm that selects.

We don’t deploy strategies. We deploy a process that re-deploys itself nightly.

Presentation source, May 2026

This has a consequence for how the system is validated. Any single night’s portfolio is one draw from the process, and freezing it for two weeks to “test” it discards the daily rotation that the design treats as its source of value. The platform therefore registers the process immutably and treats each next-session trade as a one-day-forward out-of-sample test of the framework rather than of a snapshot.

Scope and sources

This document describes the system as it stood when active development paused in July 2026. It is compiled from the project’s own artifacts: the foundation document the team called the platform’s constitution, the decision log numbered D-0001 to D-0026, the canonical pipeline reference for version 3.2, the execution engine’s operational guide, the pre-registered signal specifications, and the source itself. Where a design choice was motivated by an empirical finding, the reasoning is given.

It describes design and mechanism, not performance. No returns, pass probabilities or account outcomes appear here. Account, broker and server identifiers have been removed.

2025: hand-built systems

LQ did not start from a blank page. Through 2025 a series of Python trading systems, internally numbered as Lydon Systems, worked through the problems that the factory would later industrialize. The most developed, ls3, traded United States equities and options through a retail brokerage API and contained, in embryonic form, most of what LQ would need.

• Strategies as classes with parameters. A daily “hyper-growth” momentum strategy on leveraged technology ETFs, entering on RSI crossovers with ATR-scaled stops and targets and up to four concurrent positions; and an intraday scalping strategy on the same universe with EMA crossovers, a volume spike filter, a VIX regime threshold, a broad-market trend filter, and a rule against shorting leveraged products.
• A walk-forward backtester with an explicit transaction-cost model: slippage in basis points, half-spread, borrow cost for shorts, and commission. Rolling in-sample and out-of-sample windows rather than a single split.
• Regime detection. Six regimes (bull and bear at low and high volatility, sideways, recovery) derived from moving-average trend, VIX bands and realized volatility, with position sizing multipliers per regime.
• A risk manager with states. Normal, reduced, defensive and halted, driven by daily-loss circuit breakers, drawdown limits, single-position and total-exposure caps, and a cap on correlated positions.
• Options machinery. Black–Scholes pricing and implied volatility, a liquidity filter on chains, and a fractional Kelly position sizer that tracked realized win rate and payoff ratio by strategy and regime. Three options strategies sat on top: same-day SPY expiries, weekly calls on leveraged ETFs, and an explicitly maximum-risk momentum variant.
• Operations. A live trader with a trade logger, performance tracker, alert system and Docker and systemd deployment files, run in paper and then live modes in late 2025.

What carried forward was the apparatus: walk-forward validation, cost modelling, regime awareness, kill switches and Kelly-style sizing. What was abandoned was the unit of work. In ls3 a human chose parameters, ran a backtest, read a summary table and chose again. The project notes from mid-2025 describe wanting the program to iterate through strategies and parameters itself and report all the results afterwards. That wish is the seed of the factory.

Two smaller systems from the same year, an options volatility breakout bot and a news-sentiment forex bot, explored adjacent ideas and were set aside.

Early 2026: the first factory

The first version of LQ proper was written in March and April 2026 and was already described as an autonomous systematic trading factory purpose-built for CME futures evaluations. Its shape is recognizably the ancestor of the final system, but it searched differently.

• Data. One-minute bars for six liquid contracts (ES, NQ, YM, RTY, GC, CL), roughly 700,000 bars per instrument across two years.
• A regime classifier. A five-state hidden Markov model labelled calm, trending up, trending down, mean-reverting and transitional conditions, and a regime monitor rotated the deployed strategy when the posterior shifted.
• A predicate library. Eighty-two self-registering boolean conditions across twenty-seven categories, from candlestick microstructure and time-of-day windows to permutation entropy, Hawkes branching ratios, path signatures and discrete Ricci curvature. Each had typed parameters with valid ranges; the factory sampled them stochastically to build entry rules.
• A five-phase pipeline. Explore (a broad random mine over predicate combinations), Exploit (parameter perturbation around survivors), Validate (Monte Carlo simulation under the evaluation rules), Funded (re-validation under funded-account rules) and Report (writing survivors to a SQLite strategy pool with regime coverage tracking).
• A validation stack of in-sample filter, regime gate, evaluation and funded Monte Carlo, walk-forward stability, consistency rule check, Kelly sizing and a final withheld holdout.
• A mathematical model library of seventy-two classes (Section 5.3), a desktop dashboard built with Tauri and React, and a session trader on a virtual private server that executed a simple opening-breakout rule through a futures gateway.

That breakout rule deserves a sentence because it outlived the factory that produced it. Enter one point beyond the opening price captured by the first bar after 09:30 Eastern, inside a 10:15 to 15:30 window, with a symmetric bracket of twenty-four ticks placed server-side, at most one entry per day per account, a daily gain cap, and a forced flatten at 16:30. It became the production configuration while the research system beneath it was rebuilt, and its structure, a gated single-entry bracket expressed as data, became the template for every strategy the engine would later run.

The halt and the foundation

In April 2026 the project stopped production trading and wrote its constitution. The document, LQ Foundation, opens with one goal stated once, and then draws four boxes with arrows pointing up. The reason for the halt is recorded in the specification for the measurement engine that followed: the earlier search had run a large number of trials without pre-registration or any accounting of how many things had been tried, so nothing it reported could be trusted. Building an honest evaluator was described as how the project would earn the right to trade again.

Several large components were archived rather than deleted: the predicate library, an earlier Markowitz-style composite, the regime oracle, and the legacy strategy miner. The archive note keeps them as reference material. What replaced them is the subject of the rest of this document.

Nine hundred and nineteen commits between 20 March and 4 July 2026, in a repository of roughly 1,340 Python files.

The two games

The evaluation phase and the funded phase are different optimization problems, and the foundation insists on treating them as such.

Game 1, the evaluation, is a race to the target before the loss line, subject to the consistency rule. Its objective is a time-adjusted pass rate, written TAPR, the pass probability divided by the expected days to pass. It tolerates variance if variance serves speed: a higher conviction threshold, fewer trades, larger size relative to the account.

Game 2, the funded account, is the extraction of a monthly income while never breaching the loss line. Its objective is the monthly extraction rate multiplied by the expected lifetime of the account, where the extraction rate is bounded by the program’s payout ladder. It suppresses variance and prioritizes survival: a lower conviction threshold, more trades, smaller size.

The research plan from April works the two games into a common vocabulary. For the evaluation: pass probability, expected days to pass, blow probability, the daily profit-and-loss distribution, maximum adverse excursion and a consistency score. For the funded phase: monthly extraction rate, survival probability over a horizon, expected lifetime and drawdown recovery time. The break-even condition joins them: an evaluation is worth attempting when its pass probability exceeds the ratio of its cost to the funded expected value, and the interesting question is where on the pass-probability-versus-time curve the combined expected value is highest.

The design resolution is that the same signal serves both phases with different execution parameters. Signal is what the mathematics says; execution is how the system acts on it. Each candidate therefore produces two strategy registrations, one for each phase, generated from the same composite by transforming only its execution block. A dedicated module, the phase switch, performs that transformation, and the execution layer routes the right variant to each account according to its current phase.

What the geometry demands

Three design consequences fall out of the rule table, and they recur throughout the system.

1. Magnitude scaling is forbidden. If position size were proportional to conviction, a high-conviction day would produce an outsized result and trip the consistency rule. Fixed size per fire gives the daily distribution an independent, identically distributed shape by construction.
2. The left tail must be bounded. The maximum loss limit is left-tail risk. A fixed-size bracket with a server-side stop makes each fire’s worst case known and small, so a day’s loss is controlled by the stop multiplied by the number of fires, never by a runaway position.
3. Measurement must target what the executor pays out on. If the trade rule is a symmetric bracket, a signal should be scored against the realized outcome of that bracket, not against the next bar’s return. Section 6.2 takes this up.

The project summarized the resulting separation of concerns as three layers with three single knobs and no entanglement: signal selection optimizes predictive correlation against the bracket outcome; the trade rule maps a composite to fires at fixed size; and the evaluation geometry tunes thresholds, bracket width and account sizing to the pass profile. Nothing crosses lines.

Four layers

The foundation’s whiteboard is four boxes with arrows pointing up. Layers are strict: layer N talks only to layer N−1 and N+1. Execution does not reach into the data layer; measurement does not know what a strategy is; construction does not compute predictive correlations; the model library does not know it is being traded.

Layer 1, data and models, owns one parquet file of one-minute bars per instrument in a canonical schema, with contract rollover handled by back-adjustment and session metadata on every bar, together with the model library: pure functions from bar arrays to typed numbers, each declaring its native resolution, required lookback, output type and source. It owns no notion of strategy, fit, weight or performance.

Layer 2, signal measurement, has one job: for each cell, measure predictive correlation on a pre-registered holdout, report it with deflation against the project’s cumulative trial count, flag low-sample cells, and publish three correlation matrices. Its outputs are append-only tables. It measures things; it does not use them.

Layer 3, strategy construction, turns the measurement table and correlation matrices into per-instrument candidates expressed declaratively, composes them with weighters that are benchmarked side by side, builds the cross-instrument portfolio, and emits the deployment artifact. It does not measure, execute, or retune anything after registration.

Layer 4, execution, runs three services on one server: the out-of-sample tracker that grades registered strategies forward on live data without placing orders, the production engine that trades promoted configurations, and the continuous loop of ingest, freshness checks, rotation candidates and multi-account orchestration. It executes what Layer 3 produced and proposes rotation candidates back into the gate. It holds no research logic.

The nightly loop

The data flow is a loop with no side channel. New bars arrive; the model library recomputes signal outputs over the new window; measurement appends new rows; construction re-ranks candidates; a freshness check asks whether what is deployed is still the best candidate; if not, a rotation candidate is emitted into the tracker and, eventually, through the promotion gate. In the nightly operational form the loop ran as follows.

1. After the close, a cron job on the server pulls the day’s fifteen-minute bars for the whole instrument universe into per-instrument parquet files.
2. A scheduled orchestrator on the research workstation checks that the cell cache is current, regenerates cell streams for the new day, aggregates the day’s shadow results and posts them to the dashboard database.
3. The nightly selection re-measures every cell, builds composites and the portfolio, writes tomorrow’s YAML and an audit record, and deploys both the YAML and the signal library to the server in one atomic operation. The service restarts with the new configuration.
4. In the next session the engine evaluates bars, fires entries inside each strategy’s gate window, and emits fill events to the dashboard’s ingest function. The public dashboard subscribes to those rows and updates within a second.

Where the code lives

Data

The instrument universe was thirty-three CME-group futures across five asset classes: equity index (ES, NQ, RTY, YM and their micros MES, MNQ, M2K, MYM, plus NKD), foreign exchange (6A, 6B, 6C, 6E, 6J, 6N, 6S), energy (CL, MCL, NG, QG, QM), agriculture and livestock (ZC, ZL, ZM, ZS, ZW, HE, LE) and metals (GC, MGC, SI, PL, HG). A later decision trimmed the tradable set to the twenty-seven or twenty-eight contracts the target program actually permitted; cells were still measured on the rest.

Three data assets fed the system. Two years of one-minute history for the six original contracts, roughly 700,000 bars each, sourced from a market-data vendor. Vendor pulls of one-second bars, trades and, for ES, full order-book messages for about twenty-seven instruments covering the first four months of 2026, held for microstructure work. And the production feed: a nightly backfill of fifteen-minute bars for the whole universe pulled through the futures gateway on the server, which is what the nightly pipeline actually measured against.

The canonical schema is a timestamp and five fields, open, high, low, close and volume, one parquet per instrument, with rollover back-adjusted so there are no gaps at contract boundaries, session flags per bar, and a declared missing-data policy: a bar with zero volume during regular hours is flagged, never silently filled. The primary research resolution was fifteen minutes, with one-minute data retained because simulation at one minute reveals intra-bar stop-outs that fifteen-minute bars hide. A point-in-time loader guarantees that any value computed for a decision date uses only data with earlier timestamps.

The model protocol

A model in Layer 1 is a pure function. Its input is arrays of bar data; its output is a number or array with a declared type drawn from a small vocabulary: a z-score, a probability, a level, a ratio or a count. Each model declares its native resolution, the lookback it requires, its output type, and a source tag that is one of ta, math or custom. Adding a model is a deliberate act: tests, a catalog entry and a specification. The library was meant to grow slowly.

Two classifications accompanied each model in the April research plan. One sorted models by what they measure, roughly whether they describe the current state of the series or predict its change. The other recorded the resolution at which the model was most informative, so that a translation layer could align a signal computed at its native resolution to the fifteen-minute execution grid. The translation function existed as a placeholder through most of the project; in practice the production families were all computed on the execution grid directly.

The mathematical library

The seventy-two classes in the model library are the research page’s nine domains written as code. They are grouped by module.

Not everything in this library reached the nightly pipeline. The library was the research surface; the production signal families described next were the subset that passed through the model protocol and a pre-registered specification.

Signal families in production

A signal family is a function in lq/math together with the parameters that change its behaviour. By late May 2026 there were 161 pre-registered family specifications in twenty-eight mechanism categories, falling into three classes.

Academic and mathematical adapters wrap the model library into fifteen-minute signals: GARCH persistence, Shannon and spectral entropy, autocorrelation profile, Ornstein–Uhlenbeck reversion speed, the variance ratio, Hurst exponent, dollar volume and liquidity indices, volume dispersion, signed streak length, bars since an extreme move, tail intensity, trend efficiency, realized skew and kurtosis, range expansion, distance from peak, and a family of session-structure signals that lock in an early-day value such as the first-hour return or the position of price in the opening range and broadcast it to the rest of the session.

Technical indicators were included deliberately and measured on exactly the same footing: RSI, ADX, MACD, Bollinger z-score, ATR ratio, cumulative-volume-delta slope, money-flow index, Williams %R, distance from a moving average and realized-volatility ratios, each at several lookbacks and holding periods, each sliced by asset class.

Themed research signals, numbered 001 to 009, were authored from mechanism hypotheses and are the most characteristic part of the universe. Each has a specification describing its mechanism in prose before any mathematics.

Later extension sets added microstructure proxies from bars (signed volume, VWAP acceleration, range-break position), overnight-gap dynamics, volume-regime-adaptive momentum, and pairwise cross-asset primitives such as spread z-scores, correlation breakdown and lead–lag correlation. Appendix B lists the twenty-eight mechanism categories with family counts.

Custom signals as first-class citizens

The foundation is explicit that custom signals are not a separate path. A natural-language idea, an operator hypothesis or a market-structure observation, is turned into signal code that satisfies the same protocol, carries a custom tag, and is measured by the same machinery. The document’s reasoning is that public mathematics libraries are crowded, and the creative flashes are not. The specifications preserve the original framing verbatim. The cross-asset residual family opens with this:

If all stocks, commodities, futures, etc. all feel the same effects of the same parameters, doesn’t the answer to predicting them lie in their relation to one another? Since we will never have all the factors necessary to solve the market, why not reframe the problem so we can cancel out those parameters, similar to cancelling out the same variables in two equations and relating them.

Pre-registration of SIGNAL-001, April 2026

The specification then supplies the three-sentence mechanism the framework requires, a pre-committed hypothesis including the sign of the expected correlation and a condition that would refute it, and a secondary expectation about the cross-asset matrix: if the signal computed on one index future is as predictive of its siblings as of itself, it has rediscovered a common factor rather than isolated an idiosyncratic one. That habit of writing down what would count as failure before measuring is the subject of the next section.

The cell

Every prediction the system makes decomposes to one atomic unit. In the May design a cell was the tuple of signal family, parameters, bar resolution and instrument. By version 3.2 the cell had absorbed the trade geometry as well, because the measurement target depends on it:

cell = (signal_family, instrument, resolution, tgt_dollars, z_threshold, min_bracket_ticks)

SIGNAL-007_asymmetric_variance__metals_c89_SI_15m_tgt1200_z1.0_bk4
│                                  │       │   │   │       │     └ minimum bracket width in ticks
│                                  │       │   │   │       └ fire long at normalized signal ≥ +1.0, short at ≤ −1.0
│                                  │       │   │   └ symmetric bracket dollars per fire (target = stop)
│                                  │       │   └ bar resolution
│                                  │       └ instrument
│                                  └ enumeration index of the parameter set within the family
└ signal family and asset-class slice

With roughly 150 families, three to five parameter sets each, two or three resolutions and thirty-three instruments, the universe was on the order of 60,000 atomic measurements per decision date; the content-addressed cache held about 216,000 cell daily-PnL streams by late May. The point the design makes repeatedly is that this is a finite, enumerable set. The question is wall-clock cost, not feasibility.

Prediction streams and the information coefficient

A cell evaluated over time produces a prediction stream, the signal’s output at every decision point. Scored against realized outcomes it becomes an IC stream, a running predictive accuracy. The information coefficient itself is a Pearson correlation between signal value and the scoring target, computed over a trailing sixty-day training window and separately over the next out-of-sample day.

Two choices in this definition are not obvious and both are logged as decisions.

The target is bracket profit-and-loss, not the next bar’s return. A signal that perfectly predicts direction can have zero correlation with the outcome of a fixed bracket if the move never reaches the target before reversing. Measuring against next-bar return selects signals that predict short continuation; measuring against the realized, signed dollar outcome of an immediate bracketed trade using the executor’s actual rule, with timeouts counted as zero, selects signals that predict favourable resolution at the bracket. Only the second is what the executor pays out on. The cost is accepted explicitly: changing the bracket rule invalidates the measurement and forces recomputation, which is correct, because the measurement was never bracket-independent.

Correlation is scored on the raw signal, not on realized Sharpe. An earlier version ranked cells by the mean over standard deviation of their realized daily bracket PnL. Because bracket PnL is quantized to plus or minus the bracket, that statistic is noisy over short windows, and ranking on a noisy estimate amplifies the winner’s curse. The underlying correlation between signal and outcome is continuous and smoother, so it was adopted as the ranking statistic.

A stability gate sits on top. The training window is split into four equal sub-windows and a cell is admitted only if the sign of its IC agrees with the full-window sign in at least three of them. An earlier four-of-four version was found to reject genuine candidates on the strength of one weak fortnight; the relaxed form was described as the single most effective overfitting filter in the pipeline.

A sixty-day IC that’s carried by one good week isn’t a signal. It’s noise wearing a costume.

Presentation source, May 2026

Pre-registration, trial budgets and deflation

Measurement in LQ is a registered act. A specification file carries YAML front matter declaring the function to be measured, the grid of instruments, resolutions, directions, lookbacks and holding periods, the holdout window, and the survival threshold, followed by the mechanism and hypothesis in prose. The measurement engine refuses to register a specification while the working tree has uncommitted changes: pre-registration is only meaningful if the specification is in version control first. Registration atomically increments a trial budget, the single running count of cells the project has ever measured, and every row subsequently reports deflated Sharpe and deflated IC against the cumulative count at the time of measurement, after López de Prado.

spec_id: SIGNAL-006_failed_intent
function: lq.math.failed_intent.failed_intent_signal
grid:
  instruments: [MES, MNQ, M2K, ES, NQ, RTY, YM, MYM]
  resolutions: [15]
  directions: [long, short]
  lookbacks: [20, 40, 80]
  holding_periods: [1, 4, 26]
holdout:
  start: "2026-01-22"
  end: "2026-05-08"
threshold:
  deflated_sharpe_probability: 0.95
  n_obs: 500
  primary: raw

Each row of the measurement table records the spec, the cell index, instrument, resolution, direction, lookback and holding period; the holdout bounds; raw IC and translated IC; a serialized cross-asset IC matrix; the observation count; observed and deflated Sharpe; the trial count at measurement; the git commit; and a set of stability diagnostics: IC over each half of the holdout, the fraction of calendar weeks whose IC sign matches the full-sample sign, the same fraction excluding the three heaviest weeks, and the share of the correlation mass those three weeks carried. The table is append-only. A cell below a minimum number of effective observations is reported but flagged low_n, and the selection layer is forbidden from choosing a flagged cell without an explicit override.

Specifications are immutable once in use. Amendments are new specifications. The pre-registration file for a holdout window that had to be adjusted, because the gateway’s historical API only reached back to a given date, records the amendment and the reason rather than editing the original.

Correlation structure

Beyond per-cell correlations, Layer 2 publishes three matrices that selection consumes and the dashboard renders as heat maps.

• Signal to signal: do two signals’ outputs co-move? High correlation means the same edge wearing two names; low means independent information.
• Instrument to instrument: do two markets’ forward returns co-move? This is what determines whether trading them together diversifies anything.
• Signal-per-instrument cross matrix: for signal A on instrument X and signal B on instrument Y, how correlated are their joint outcomes? This is the matrix the portfolio layer reads when assembling candidates whose realized results are not tightly linked.

The correlation engine built these over a common window across all 151 active specifications and twenty-seven instruments, with low-sample pairs flagged. A separate nightly job computed each cell’s tail IC, its predictive correlation conditioned on the days that mattered most, with a sign-stability flag, and an evaluation board ranked the best stable cell per instrument from it.

Cadence, cache and audits

Every cell is re-scored every night after the close. The full sweep was parallelized per instrument and took a few minutes of wall-clock time on the research workstation. Behind it sits a content-addressed blob cache with hashing, an index, an LRU policy and garbage collection, so that unchanged cell streams are never recomputed and the nightly cost is dominated by the new day.

Two audits protect the measurement. A point-in-time correctness audit replays each signal family’s computation to confirm that no value at a decision date depends on later data; all forty-nine audited families passed. And each dashboard payload has a frozen-output golden test, so a change in the payload builder that alters a number the dashboard reports fails the suite.

The gate cascade

Version 3.2 runs candidates for an instrument through a cascade of admission gates, cheapest first, all of which must pass.

1. IC threshold. The absolute full-window IC must be at least 0.02, a lower bound separating potentially real signal from certain noise.
2. Three-of-four stability, as described above.
3. Top 200 by absolute IC, a cheap pre-filter before the expensive gates.
4. Skewness bound. Cells whose daily-PnL distribution is too skewed are dropped, on the reasoning that symmetric distributions suit a barrier geometry.
5. Trailing alpha. A cell whose net PnL over the trailing thirty days is not positive is dropped; the gate was found to compose super-additively with the next one.
6. Standalone Monte Carlo floor. Each survivor is simulated alone against the evaluation rules and must clear a minimum pass probability. The reference notes that point-in-time values differ materially from an older look-ahead-tainted cache, and that the threshold must be calibrated on the former.
7. Win rate. Per-fire and per-day win rate above one half, treated as a primary gate rather than a tiebreaker.

Greedy admission with two correlation gates

Survivors are sorted by absolute IC. The first is admitted. For each remaining candidate, two gates are evaluated against the running composite and both must pass.

Gate A, marginal IC after residualization.Regress the candidate’s prediction stream on the composite’s prediction stream, take the residual, and score the residual’s IC against the target. Admit only if that residual IC stays above the threshold. By construction the number is the additive contribution. This rules out structural redundancy: two trend-strength indicators at adjacent periods, or two non-linearly overlapping transforms of the same quantity.

Gate B, daily-PnL correlation. The Pearson correlation between the candidate’s realized daily PnL and that of every admitted member must stay below a ceiling of 0.85, with a tighter target explored. Two predictions can be structurally orthogonal and still fire on the same days, for instance because both are threshold-crossing signals whose thresholds align with volatility. Co-firing is what breaches a loss limit, and the loss limit lives on the daily-PnL surface, not the prediction surface.

Each admitted cell is scaled by the ratio of its training-window standard deviation to a target of $250 per day before summation, so that no single cell dominates by having naturally larger swings. Admission stops at six members, the cap implied by the program’s position limits, or when no candidate passes both gates. The result is one composite per instrument with one prediction stream, one realized daily-PnL stream and one trailing Sharpe ratio.

Three refinements were designed, tested and shelved rather than adopted, and the decision log keeps them: a tail-conditional correlation that measures co-movement only on shock days, since average correlation is dominated by calm days; disjoint training walks so that a cell must survive genuinely independent windows; and a requirement that a cell’s marginal contribution to Monte Carlo pass probability exceed two standard errors rather than merely be positive. Each addressed a real issue. Stacked on top of the other gates, each filter passing a fraction of its input, they left too few candidates to compose. The log’s conclusion became a rule: layer one change at a time and measure its effect at the portfolio level.

Composers

How admitted members are weighted is a separate, pluggable question. The foundation requires that multiple weighters run side by side on the same input, that their outputs be benchmarked against each other, and that the chosen weighter be recorded with each registration so a structurally better one can displace the incumbent through the same promotion gate as any other change. The composer library contains equal weight, IC-weighted, ridge regression, hierarchical risk parity, a Kelly fraction, a correlation-deflated IC weighter, a greedy orthogonal IC weighter, and the production linear weighter, which weights signals by deflated importance under a constrained mean-of-correlations objective. The additive builders exist in three versions, the third carrying the OLS residualization, win-rate filter and PnL scoring described above.

The instrument filter

Each surviving instrument now has a composite. The entry gate to the cross-instrument layer is a filter on the composite’s trailing-window Sharpe ratio: an instrument whose composite is not positive over the recent training window is dropped before combination. The reasoning recorded in the log is that an equal-weight sum across streams of mixed sign produces a portfolio worse than its best members, and that the deployment-relevant question is whether the portfolio, which is what trades, clears the evaluation, not whether individual instruments do. Combination therefore happens after filtering, and the pass probability is evaluated on the combined daily series.

The original design then applied a modern-portfolio-theory style decorrelation: among survivors, choose up to four instruments whose composites are mutually as uncorrelated as possible, using realized daily-PnL correlation between the composite streams. Version 3.2 replaced the fixed count with mode-specific rankers.

Evaluation mode and funded mode

Layers 1 and 2 are shared. Layer 3’s ranking, sizing and thresholds differ by the game being played, and the nightly orchestrator toggles between them with a single flag.

Evaluation mode ranks each instrument’s candidate variants by a chronological Monte Carlo: each of the trailing thirty days becomes a hypothetical evaluation start; the simulation walks forward applying the daily floor, counting a pass when the balance reaches the target and a failure when it falls to the trailing limit; the pass fraction across starts is the score. The account profile for this mode scales contract size to keep single-trade risk inside the daily loss limit, caps the day’s upside so that one day cannot dominate total profit, and refuses entries once the day’s loss reaches a floor.

Funded mode ranks by what the deploy engine can actually realize: each variant’s daily PnL is scaled by the contract factor, clipped to the day’s floor and cap, and the mean of the clipped series is the score. A large day that would have been capped is capped before the mean is taken. A per-fire band filter then picks, among the bracket variants of the same composite, the one whose mean per-fire dollar magnitude lands nearest a target that corresponds to the program’s qualifying-day floor. Finally a greedy, correlation-aware pick assembles the portfolio: start with the highest-scoring survivor, and for each remaining candidate multiply its score by one minus a penalty times its maximum absolute correlation with anything already picked, stopping at a maximum count or when the program’s contract cap is reached.

The two Layer 3 configurations share every cell and composite. The same composite can deploy at a different bracket size in each mode.

The reference is careful to say that this is neither pure portfolio theory nor pure top-N. Pure portfolio optimization would solve a quadratic form over weights without the per-fire band or the contract cap; pure top-N would ignore correlation. The production rule is greedy, correlation-aware, band-filtered and cap-bounded, and the band filter is what lets Layer 3 choose the right bracket variant for the funded goal versus the evaluation goal from the same cache.

The trade rule

A composite becomes a trade through a pure threshold and a fixed-size bracket. Fire long if the normalized composite exceeds an upper threshold, short if it falls below a lower one, otherwise stay flat. One bracket per fire, fixed contracts, stop and target placed server-side. No magnitude scaling, no tiered sizing. Section 3.2 gave the reasons; the practical consequence is that the daily PnL is a sum of bounded outcomes whose left tail is the stop times the number of fires.

The threshold is a calibrated parameter rather than a free knob. It is chosen so that historical fire frequency, per-fire win rate and bracket size together give the daily distribution the shape the evaluation geometry rewards: several modest profitable days rather than one large one. A high threshold means fewer, higher-conviction fires; a low one means more fires and smaller per-day variance. Bracket size itself is enumerated: cells exist at several symmetric dollar brackets per fire, typically 300, 500, 800 and 1,200 dollars, with a floor on bracket width in ticks so that low-volatility conditions cannot produce an absurdly tight stop.

One correction in the log concerns how a multi-cell composite is expressed to the engine. The research model sums the realized PnL streams of independent cells, each firing its own bracket. An earlier emission summed weighted, z-scored signal values into a single scalar that fired once per bar, which is a different strategy with a different distribution. The emitter was aligned to the research model: one strategy block per admitted cell, several blocks on the same instrument, their results summing at the account.

Emission

The nightly output is a single YAML file: the entire deployment artifact. It lists the instruments, the engine settings, and one strategy block per admitted cell, each naming the signal function by import path, its parameters, the firing threshold, the gates, the bracket, the daily floor and cap, and the end-of-day flatten time. Emission is profile-parametric: the same selection algorithm, with different sizing, caps and qualifying thresholds for each program and account size, drawn from account profiles that encode the rule tables.

The emitter writes an audit record alongside the YAML, recording which cells were considered and why each was admitted or rejected, and the deploy script refuses to ship a YAML whose function references do not exist in the mirrored signal library. Both artifacts, the YAML and the audit, are what the dashboard’s walk-forward and emission panels are built from.

Methods

The validation methodology, as the system described itself, had seven parts. Walk-forward validation that fits on the past and scores on a held-out future, with a sixty-day training window and a thirty-day test window as the working convention. Monte Carlo simulation of daily PnL against the evaluation rules, by bootstrap, at 50,000 paths per parameter set repeated across thirty random seeds, with CPU and GPU implementations for each program’s rule set and a variant that includes the engine’s risk overlay. Bootstrap confidence intervals on win rate and pass fraction. Combinatorially Symmetric Cross-Validation to estimate the probability of backtest overfitting. Pre-registered specifications with the hypothesis stated and hashed before measurement. An out-of-sample tracker that holds paper-traded candidates apart from live capital. And a promotion gate in which a single ledger file is the only door.

Two further habits deserve mention. The first is deflation: no Sharpe or IC is reported without adjustment for the project’s cumulative trial count. The second is the preference for distributions over point estimates. Monte Carlo noise is small relative to variation across market regimes, so the project’s later documents require results be reported as a band across folds rather than a single figure.

The out-of-sample tracker

The tracker is described in its specification as the commitment device that ends the refactoring loop. It is a service on the server that receives strategy registrations as JSON and simulates them forward-only against live market data. It is not a backtester: it operates only on bars received after the registration timestamp. It is not a trader: it has a market-data connection but no order route. And it is not mutable.

A registration is written to a directory, immediately copied to a content-addressed immutable store with its SHA-256 hash, and the original is made read-only. Every scoring event references the hash. If the live file ever diverges from the immutable copy, the tracker refuses to score the strategy and logs a tamper event. A new version of a strategy is a new registration with a new identifier. The registration schema requires a one-paragraph description and a one-sentence hypothesis, the instrument and resolution, the signal and its parameters, the execution block (contracts, stop, target, maximum entries per day, cooldown, session flatten bar), a friction model (slippage per side, commission per side, point value), and termination rules: a hard minimum number of days before it may be killed, an optional maximum, and kill criteria on realized Sharpe, cumulative PnL or trade count.

On each fifteen-minute bar the evaluator checks every registered strategy on that instrument, records hypothetical entries at the next open plus slippage, checks stops and targets against the bar’s high and low, records exits with the declared friction, and flattens at the session bar. Fills append to a per-strategy log; a daily summary writes to a SQLite database; a spreadsheet with a leaderboard and one sheet per strategy syncs to the workstation. A terminated strategy stays in the database and cannot be un-terminated.

Promotion and milestones

Promotion from the tracker to production is a separate, explicit act with pre-registered criteria: a minimum number of trading days alive, a running Sharpe above a threshold, positive cumulative PnL, a win rate within five percentage points of any prior backtest claim, and a manual review committed to the ledger with the strategy identifier and the rationale. The ledger entry schema records the registration hash, the days graded, the measured forward statistics, the accounts and phase, explicit demotion criteria committed in advance, and a sign-off. When promoted, the exact immutable JSON is copied to production without change; if change is needed, a new strategy is registered and the clock starts again. A strategy exists either in the tracker or in production, never both.

Above this sits a milestone ladder in three tracks, architectural, research and commercial, where each commercial milestone requires a research milestone, which requires architectural ones. The status line in the milestones file is the halt rule itself: no production trading until the first promotion event. The first promotion bar was set deliberately low, twenty days, to make the commitment device feel real within weeks, with a recorded intention to raise it to sixty or more days and a trade-count floor after the first cycle.

The decision log

Every architectural or parameter choice in the pipeline has an entry: the concrete change, the reasoning, the predicted effect with a magnitude where possible, the empirical result once run, and a status of active, superseded, shelved or refuted. Decisions that proved wrong are not deleted; they are marked and linked to their replacement. The discipline note at the end states that a change implemented without an entry is to be reverted until the entry is written, because the point is to make the reasoning explicit for whoever reads the code later. Appendix A indexes the twenty-six entries.

The engine

The production engine is a single Python process, run as a systemd service, that holds no strategy logic. It loads whatever the YAML describes. The project’s phrase was that the engine is dumb on purpose: the factory ships the strategy as data, so no engine change is needed to trade a new strategy family.

The YAML is validated against Pydantic models in strict, frozen mode, with a dedicated validator that rejects any time literal not qualified with the Eastern time zone. The vocabulary is twenty-two primitives, each a small evaluable class in a registry:

A strategy is a named block binding an instrument and an account to references, a set of gates, a long condition, a short condition, an order specification and a flatten time. The production breakout rule, which served as the schema’s first configuration, reads as follows, with identifiers removed.

strategies:
  - name: ST1
    account_id: <account>
    instrument: MES
    references:
      sopen: {type: first_bar_open_after, time: "09:30 ET"}
    enter:
      gates:
        - {type: time_between, start: "10:15 ET", end: "15:30 ET"}
        - {type: max_per_day, count: 1}
        - {type: daily_pnl_under, cap: 1200.0}
      long:
        type: gte
        lhs: {type: bar_high}
        rhs: {type: sum, terms: [{type: ref, name: sopen}, {type: constant, value: 1.0}]}
      short:
        type: lte
        lhs: {type: bar_low}
        rhs: {type: diff, lhs: {type: ref, name: sopen}, rhs: {type: constant, value: 1.0}}
      order: {type: market_bracket, size: 30, stop_ticks: 24, target_ticks: 24}
    eod_flatten_at: "16:30 ET"

The runtime builds one strategy object per block, maintains a rolling buffer of two hundred bars per strategy, dispatches incoming bars by instrument and fills by account, and on each bar performs day rollover, reference capture, end-of-day flattening, gate evaluation and signal evaluation in that order. All time gates are evaluated against the Eastern wall clock, never a bar timestamp, a rule that pins a real defect in which naive UTC timestamps on the server once produced entries four hours early. Per-account state, today’s date, the session open, whether an entry has been made, the day’s PnL, whether the day is capped, and the open position, is persisted to a JSON file on every bar and every fill by atomic write. High-water mark, loss limit and consistency are deliberately not tracked in engine state; those live on the program’s portal, and the engine only needs to decide whether to enter.

Around the core sit modules added through May and June: a dashboard sink that posts fills and end-of-day summaries to the ingest function; a hedge guard that asserts no two accounts hold opposite directions in the same or a correlated instrument; a reconciliation module that rebuilds position truth from the fill stream rather than from engine state; a shadow module that evaluates registered candidates alongside live strategies without placing orders; and an account ledger with an event-sourced command-line interface covering the lifecycle of evaluation purchase, pass, activation, payout and close. The engine package is about seven thousand lines; its own suite holds roughly 285 regression cases, and the repository as a whole close to two thousand test functions across 229 files.

Broker integration

One module, and only one, touches the futures gateway library and its protobuf messages. It decodes bars from naive UTC into Eastern-aware timestamps and fills from protobuf into a typed dataclass with canonical field names. It resolves a base symbol to the front-month contract at every submission from subscription state, because the gateway trades only contract months. Entries are bare market orders; the bracket’s stop and target are placed as separate orders only after the entry is confirmed complete, and bracket placement and sibling cancellation are scheduled as tasks rather than awaited inside the fill handler, because the library delivers callbacks on a single dispatch task and awaiting a submission from inside a handler blocks the very response being waited for. A submission timeout is treated as unknown rather than failed, since the gateway often fills regardless.

Each of these sentences corresponds to a numbered row in the engine’s bug-history table, sixteen in all, every one fixed, lost in a rewrite, rediscovered, and finally pinned by a named regression test so that touching the broker or runtime modules without re-reading the table fails the suite before deploy.

Gates and kill switches

Risk control is layered from the YAML outward.

• Per-strategy gates in the configuration: an entry window, one fire per session, a daily gain cap after which no further entries are added, a daily loss floor after which the strategy halts, and a forced flatten at the end-of-day time.
• The risk overlay, an account-wide layer: a rolling five-day pause that halts an account when its cumulative PnL over the window crosses a threshold, with a recovery period; and a terminal balance breaker at the program’s loss floor.
• The watchdog: any position whose entry is partially filled and unprotected after thirty seconds is flattened, and any position whose entry shows no fill after a grace period is treated as a phantom and cleared, because a native bracket only arms when the entry is complete.
• Process safety: an interrupt signal triggers an emergency flatten on every account before shutdown; reconnection uses linear backoff capped at two minutes with unlimited retries; and the hedge guard refuses opposite-side exposure across accounts, since cross-account hedging voids an evaluation.

The operational checklist before any restart begins with confirming on the program’s portal that every account is flat, because a restart with an open position is itself a flatten.

Deployment

The server held two independent code surfaces with two deploy paths, and the guide is emphatic that they not be conflated. The YAML and the mirrored signal library are one logical unit, deployed daily by a single script: it checks every function path in the YAML exists locally, stages the library on the server and verifies by abstract-syntax-tree inspection that each referenced module defines the expected function without import-time side effects, swaps library and YAML atomically with the previous versions retained, restarts the service only after both swaps succeed, and fails if the post-restart log window contains a module-not-found error. A rollback command is printed if it fails mid-restart. The engine itself is deployed rarely, by hand, after the full regression suite passes locally and again on the server.

The deploy script codifies a specific lesson. For a day and a half in late May the engine processed every bar and fired nothing, because a YAML referencing a new signal module had been shipped without the module file; each bar evaluation raised an import error that was logged under a library logger name and silently bypassed every entry. The pre-flight check moves that class of failure from market open to deploy time.

Infrastructure was minimal by design: one small virtual private server in a United States data centre, one systemd unit with automatic restart and graceful shutdown, one gateway connection shared by both accounts in one process, credentials sourced from an environment file on the server that never leaves it, and a standing rule that every byte running on the server is mirrored in the repository’s live-trading directory.

The nightly chain

Keeping the dashboard current requires a fresh row every trading day, and the operations guide records the failure that motivated it: for two days the chain had silently stopped because the server’s bar-backfill cron had never been installed, so bars never reached the cache, the cache never produced new shadow results, and the dashboard froze while looking alive. The remedy was a single orchestrator with fail-fast steps and distinct exit codes: determine the target trading date; gate on cache freshness and exit with a staleness message if the cache is more than two days behind; regenerate cells if needed; run the shadow aggregator; re-sync the walk-forward and emission audits. The orchestrator is idempotent, so a missed day is backfilled by passing a date.

The dashboard

Two dashboards were built. The engine-status view answers five questions at a glance and is a strict consumer of the four layers’ append-only artifacts: where research is (which cells have been measured, which flagged, what the correlation structures look like, rendered as labelled heat maps); what each instrument’s current primary candidate is, its underlying signals, its weighter, its two phase variants and whether a rotation candidate is pending; what the live deployment state is per account; and what is in the promotion pipeline, from the tracker leaderboard through candidates approaching criteria to recent promotions and demotions. It is read-only by principle: the view shows what to decide, and the decision is made elsewhere through the existing gates. Each of its payloads is produced by a builder with a golden-snapshot test.

The live dashboard on this site’s password-gated route is built on a hosted Postgres with an Edge Function for ingest and a realtime subscription for the client. The engine posts outbound over HTTPS with a bearer token on every fill and at end of day; there is no inbound exposure to the server. Six tables hold fills, open positions, per-strategy daily PnL, emission audits, walk-forward results and the shadow trail, later joined by an account ledger. Ingest is idempotent: fills and positions are keyed by account and an engine-generated tag, audits by date, walk-forward rows by date and variant, so replays are safe. The public page subscribes to row inserts and updates in under a second without any WebSocket plumbing of its own.

Local tooling

Around the pipeline grew a set of operator tools: a browser-based pipeline console; the model-library catalog with a measured-IC column; sweep harnesses including a Bayesian-optimization sweep over the version 3 builder; a weekend expansion job; and, in the final weeks, a desktop chat window backed by locally served open-weight code and vision models, intended as an R&D assistant for daily check-ins, incident triage and deploy reasoning. Its design document fixes a boundary that is characteristic of the whole project: the assistant proposes, deterministic judges such as the Monte Carlo evaluator dispose, and any action adjacent to real money stays manual.