The regime-slicing robustness fix — test in the storms, not the calm

A change to how we slice up market history when checking whether a trading "feature" is genuinely robust: instead of chopping time into bland, equal calendar windows, we deliberately pick the wildest, most extreme market periods — crashes, blow-offs, collapses — so a feature has to survive the worst the market has ever thrown at it.

In plain English. Imagine you're testing whether a car is reliable. You could drive it for two-month stretches on a flat highway over and over — but every stretch might be the same easy conditions, and you'd learn nothing about how it handles ice, mud, or a mountain pass. The old method did exactly that: it split the data into 21 identical 2-month windows, any number of which could happen to be the same calm market. The fix is to deliberately drive the car through the named disaster zones — the 2020 COVID crash, the 2021 boom-and-bust, the LUNA and FTX collapses — so a feature only "passes" if it holds up across the full range of real market chaos.

What is this?

This finding describes a concrete, ready-to-apply fix for a research tool called the orthogonality probe (orthogonality_probe.py) — the program that tests whether a candidate trading feature carries genuinely new information (rather than just repeating what we already measure). A few terms first, in plain words:

Slice — a chunk of market history (a date range for one symbol) that the probe analyzes on its own.
Cell — one slice × one trading pair × one sensitivity setting. It's the smallest unit the probe scores. (A "cell" only counts if it has enough data in it.)
Regime — a distinct kind of market mood: a crash, a bull blow-off, a sideways grind, a structural collapse, etc.
ClickHouse — the fast database (running on the "bigblack" machine) where all the market bars live; the probe only ever reads from it, never writes.
dbps — "decimal basis points," the sensitivity dial for how big a price move it takes to start a new bar. 1 dbps = 0.001%, so 250 dbps = 0.25%.

The headline problem: the old design used 21 uniform 2-month windows (a setting called _PRESPEC_SLICES, covering 2021 onward). Uniform calendar windows are a weak robustness test, because nothing stops them all from landing in the same kind of market. If every window happens to be a quiet bull market, "robust across all 21 windows" really just means "robust in one mood."

Why it matters

The whole point of the orthogonality probe is to ask a hard question: does this feature hold up across the widest possible range of market conditions? If your test conditions secretly all look alike, a fragile feature can sail through and look strong — until the market does something it never saw, and the feature breaks when real money is on the line. Picking the regimes by hand, on purpose, guarantees the test spans the genuine extremes instead of leaving diversity to luck.

The fix — three changes

1 · Add regime-named slices

Introduce a second slicing option made of 10 hand-picked crypto regimes, chosen to span the extremes (crash / bull blow-off / bear / structural collapse / etc.). Crucially, don't delete the old uniform grid — keep both.

2 · Extend the time floor back to 2018

The old cutoff (MIN_YEAR=2021) is now stale. Data is dense all the way back to 2018 for all 6 probe symbols, so the 2018–2020 regimes are now usable. (Example: the bear_2018 window in Nov 2018 holds a median of ~25,000 bars per cell — plenty.)

3 · Keep the official symbol set

Keep the probe's own source-of-truth symbol list (SYMBOL_THRESHOLDS — 6 symbols across 21 symbol×sensitivity combos). Do not swap in a raw 16-symbol database scan; the curated set is the standard.

+ Mirror it for forex

For cross-asset robustness, apply the same idea to currencies: copy the forex multislice probe (multislice_orthogonality_probe.py) — regime-named windows plus 2 trading sessions (Asian, London/NY) run against the forex bars table.

The 10 named crypto regimes

Each name is a real, memorable market episode. The exact start/end dates live in the companion audit document.

regime name	what happened (plain English)
`bear_2018`	The grinding 2018 bear market after the 2017 peak.
`recovery_2019`	The partial 2019 bounce off the bottom.
`covid_crash_2020`	The March-2020 pandemic crash — markets fell off a cliff.
`defi_summer_2020`	The 2020 "DeFi summer" speculative surge.
`bull_blowoff_2021q1`	The early-2021 parabolic blow-off top.
`may_crash_2021`	The sharp May-2021 sell-off.
`ath_2021q4`	The late-2021 all-time-high peak.
`luna_2022`	The Terra/LUNA stablecoin collapse — a structural blow-up.
`ftx_2022`	The FTX exchange implosion in late 2022.
`etf_bull_2024`	The 2024 rally driven by spot-ETF approvals.

How we know it's robust (density-verified)

Before recommending the change, the team ran a read-only "smoke test" — a quick, harmless look at the database (SELECT-only, nothing modified) — across all 20 slices (10 crypto regimes + 8 forex windows + 2 forex sessions), using the exact same symbol-and-sensitivity sets the real probe uses. The question being checked: does every regime actually have enough data in every cell? The answer was a near-perfect yes.

384

cells checked total

384

cells with data

383

clear the 1000-bar floor

empty cells

384 cells total · 384 had data · 383 cleared the minimum 1000-bar floor · 0 were empty. The "1000-bar floor" is just the threshold below which a cell has too little data to trust.
Only 1 cell came in below the floor: BTCUSDT@750 / ftx_2022 at 952 bars (just shy of 1000). This is already handled automatically by the probe's existing density gate — the built-in rule that skips under-populated cells.
The smoke test confirmed two things at once: that data really does reach back to 2018, and that every named regime is populated on every cell.

Why regime-named beats uniform 2-month

The two approaches trade off differently. Regime-named windows win on robustness; the old uniform grid wins only on one narrow technical property (a smooth, evenly-spaced series), which is occasionally useful for trend/auto-correlation math but irrelevant to the robustness verdict.

property	uniform 2-month grid	regime-named slices
Regime diversity do the windows span different market moods?	not guaranteed — could all be one regime	maximal by construction
Robustness stress how hard does it push the feature?	weak	strong — named crashes / collapses / blow-offs
Time-series regularity evenly spaced for AR/trend math?	regular	irregular — use worst-regime + spread as the robust reads

The decision: keep both. Use the regime-named slices for the robustness verdict (the "did it survive the storms?" answer), and keep the uniform grid on hand for the rare case when a smooth, evenly-spaced series is needed for an auto-regression or trend calculation. "AR/trend" here just means math that assumes data points are evenly spaced through time.

Status & provenance

Date: 2026-06-11.
Status: Density-verified via a read-only ClickHouse smoke test — and directly applicable to orthogonality_probe.py.
Full plan + per-slice density figures: the companion audit doc 2026-05-26-forward-orthogonality-prediction/COMBINED-REGIME-SLICING.md, which lists the exact date windows for every regime.

Bottom line. Swap "21 identical 2-month calendar windows" for "10 hand-picked extreme market regimes (now reaching back to 2018), kept alongside the old grid" — so a feature must prove itself across real crashes and blow-offs, not just whatever the calendar happened to serve up. A read-only data check confirmed it's safe: 383 of 384 cells have ample data, with the lone shortfall already auto-handled.

Crypto Shared Data Pool · finding · source: findings/evolution/shared_data/REGIME-SLICING-ROBUSTNESS-FIX.md · ← back to the pool · 2026-06-16