Alpha research with bar-close features — week of 21–27 July

The week at a glance

What is in this report

1opendeviationbar-research — the engine, and what it proved

1.1 · What I built — the rejector, P0 to P4, in five working days

The pipeline is a funnel of increasingly expensive tests. Cheap rejectors run first, so a bad strategy dies before I spend compute on it. Each gate targets a specific named failure mode from our FM catalog.

1.2 · What it proved — 616 rules, zero survivors

With the gates in place I pointed them at the promoted bar-close features on Friday. Three separate campaigns, three independent methods, one conclusion. I am reporting them in order of how much they cover, not chronologically.

Campaign C — the main event: 5 symbols × 120 rules

For each symbol I enumerated a complete, operator-specified grammar: 15 promoted features × 4 quantile tails (p10/p25/p75/p90) × 2 directions = 120 rules. Signals are built from past-only rolling quantiles (rolling.quantile.shift(1)), so every rule is causal by construction. Each rule is priced at worst-fill, given a moving-block bootstrap confidence interval on real resampled data, then corrected for multiple testing with both Bonferroni and BH-FDR.

Every one of the 600 rules carries verdict: "NO ALPHA" with death_reason: "no-directional-edge". Statistically: 0/600 significant under Bonferroni, 0/600 under BH-FDR, 0/600 with a positive confidence-interval lower bound. The outcome is completely homogeneous — not one rule even reached the later cost-ceiling or multiplicity branches of the decision tree, because none of them got past the first gate.

Campaign A — the BTCUSDT falsification loop

Earlier and deeper: a single feature (bar_petrosian_fd, the one producer-proven column) split into 5 quantile bins, each traded in its natural direction, each pushed through the full 8-gate failure-mode battery over 8.5 years of history.

The monotone pattern is itself informative: net P&L worsens strictly as bars get choppier (−21 → −23 → −30 → −49 → −82 bps), driven by the worst-fill cost floor rising from ~13 to ~57 bps. Choppier bars are more expensive to trade and no better directionally. There is no bin, and no direction, where the feature pays.

Campaign B — pre-flight and the 21-symbol universe sweep

Before committing compute I ran a cheap sanity sweep: 11 baseline rules on BTCUSDT (momentum, reversion, order-flow imbalance, VWAP, plus an always-long control), then a read-only ClickHouse-side sweep across the entire liquid universe — 21 USDT pairs × 4 thresholds (100/250/500/750 dbps). No rows were pulled; only medians were computed server-side.

• All 11 pre-flight rules: Dry — zero cleared even the fee-only floor.
• Across all 21 symbols at every threshold: raw directional move ≈ 0; worst-fill net −13 to −68 bps everywhere.
• Best cell in the entire grid — SHIB @ 750 dbps reversion — is +4.87 bps of move against a 25.12 bps cost floor. Still 5× short. The majors are ~16× short.

Coarser thresholds do not rescue it. The threshold sizes the move that already happened by the time the bar closes; the forward move stays ≈0 at every threshold while cost stays flat.

Why every rule died — the one chart that matters

Blue = the largest gross directional move any of 600 rules produced, before any cost is subtracted. Red = what it costs to trade, round-trip. Bars share one linear scale.

What this rules out, and what it does not

1.3 · The cross-sectional pivot — machinery built Saturday, and what I'm working on this week In flight

The machinery landed Saturday — PR #29, C1–C3: a causal panel with an as-of join, and dollar-neutral factor P&L, reviewed and tested. That is the part that is done.

C4 — the run against real data — is this week's work, and it has not started. Pulling the panel needs a ClickHouse read, which under the stop-and-ask rule I added to CLAUDE.md on Friday (#19) means writing the mini-ADR first — exact tables, columns, symbols, the precise read-only query, where it runs, and why the local slice cannot answer it. That is the next thing I do. So I am reporting this as in flight, not as a result: there are no cross-sectional verdicts yet and I have not pre-judged any.

1.4 · Monday night — CI, and eight fixes to my own engine

A rejector with bugs in it is worse than no rejector, because it issues verdicts that look authoritative. So before doing anything else with it I spent Monday night attacking my own code. Eight correctness fixes landed, plus CI.

CI landed as PR #36 — a GitHub Actions pipeline plus a /ci:* slash-command namespace, per our cross-repo standard. #41 unblocked the ruff ratchet.

Current totals for the repo: 272 test functions across 19 files.

2The new topic I opened today — subordinators New · 27 Jul

Why the clock is not a detail

Almost all market analysis starts by chopping the raw stream of trades into bars — open, high, low, close, volume. By convention we chop by the wall clock: one bar per minute. But markets do not run at a constant speed. At 3am nothing happens. During a crash, thousands of trades land per second. So a 3am one-minute bar and a crash one-minute bar carry the same label and wildly different amounts of market.

You are measuring with a ruler whose markings stretch and shrink — and then feeding those measurements to a model as if they were comparable rows in a table.

The fix is old: Mandelbrot & Taylor (1967) and Clark (1973) proposed you stop counting time and start counting activity. Close a bar every N trades, or every N dollars exchanged. Now every bar holds roughly the same amount of market. And the famous "fat tails" of returns — the too-many-extreme-moves problem that breaks standard statistics — largely go away. They were partly an artifact of using the wrong clock, not a property of the market. The mathematical name for re-indexing one process onto another process's clock is subordination (X(t) = Y(T(t))); T is the subordinator.

How the bench keeps the comparison honest

One design decision does all the work: a clock only ever answers one question — where does each bar end? It never builds the bar. A single shared piece of code turns cut-points into candles, identically for every clock. Two clocks can therefore differ only in where they cut, never in what happens afterwards. Any difference you then observe is attributable to the clock and nothing else.

Adding a new bar type costs one method and one line in the registry, and it immediately inherits every test and every comparison. There are currently 12 clocks across 8 families.

Two traps it has already found

How this connects to our ODB work

ODB is a subordinator. It is a price clock: it cuts a new bar whenever price moves a fixed distance δ from that bar's opening price. So everything above applies directly to the bars underneath every number in this report.

Its nearest published relative is the directional-change clock, and the spec pins the exact difference: DC's reference point is a trailing extremum that keeps moving with the trend (so it confirms late), whereas ODB's is fixed at the bar's open for the bar's whole life (so it cuts every δ of displacement). That single difference is the entire distinction between the two families — and until now it was an argument, not a measurement.

The honesty constraint — the part I'd most like your view on

The repo explicitly refuses to claim any of this yields profit. It cites the one rigorous head-to-head study in the literature — 60.5M EURUSD ticks, properly cross-validated, permutation-tested — which found that ranking bar types by statistical niceness did not predict ranking by trading profitability. Every family landed at essentially coin-flip accuracy.

Where it actually is, stated honestly

The test suite is the part I'd defend: six invariants × 12 clocks, plus targeted checks. The important one is C3 non-repainting — re-run the clock on a truncated tape, and already-closed bars must be bit-identical. That is the FM-01 look-ahead guard expressed as an executable assertion. There is also a scale-invariance taxonomy test that multiplies all prices by k and asserts tick/volume/DC are unchanged while dollar must change — the family taxonomy as a test rather than a comment. Per HARD RULE 5, no synthetic data anywhere: where a test needs a perturbation it uses a metamorphic transform of the real tape.

Two PRs so far. #1 is merged: an ADR rejecting my own proposal to self-host ClickHouse on a 1TB USB drive — killed on four independent grounds, including that exFAT cannot host a MergeTree at all for lack of hard links. Adopted instead: hot tier on internal SSD, cold tier as Parquet queried with DuckDB. #2 is open and substantive: the clock-zoo baseline across 6 regime-diverse days, with committed artifacts, SHA-pinned tapes, and tables auto-generated from the evidence so the prose cannot drift from the data.

3opendeviationbar-py — this week

Scope note: ODB-py has been running since April, but everything below is 21–27 July only. Earlier workstreams are deliberately out of scope for a weekly report.

3.1 · The rotational orthogonality probe — 20 candidates, and the control test that broke it

Mechanically it runs a five-stage cascade — h_norm → sibling → ρ → panel-R² → ξ — and fuses the stages by worst-of, so a candidate is only as good as its weakest stage (BAN > WATCH > PENDING > PASS). It runs on 62/62 grounded crypto cells at 80,000 bars per cell, read-only against ClickHouse on bigblack. Its intended job was to set axis.orthogonal on the candidate registry — that is, to be the promotion gate for the orthogonality axis, replacing the legacy |ρ| + h_norm banlist.

The 20 candidates I have run through it

Two batches of ten, plus smoke iterations — 22 full-cascade evaluations, and zero PASS verdicts. Every one of the 20 candidates still has axis.orthogonal deferred/null in the registry.

Batch-01 — 10 candidates

Batch-02 — 10 candidates

The test that broke the probe — and why I ran it

Twenty candidates and zero passes is either a very demanding gate or a broken one. There is a standard way to tell the difference: run the probe on things you already know are good. So I took seven features the project already ships and already labels axis.orthogonal = PASS, and fed them back through the unmodified cascade as a negative control.

I then ran the legacy probe on real data for the first time, and it has the opposite defect. Its panel carries 120 columns to the rotational probe's 112 — the extra eight being open · high · low · close · vwap · lookback_vwap_raw · first_agg_trade_id · last_agg_trade_id. In other words, the legacy probe was ranking raw price levels and a monotone trade-ID counter as redundancy drivers: self_correlation_driven was true at 7/7, and 4 of 27 candidates had a price level or row counter as their worst driver.

The verdict — PR #668, open now

The campaign verdict file states it plainly: "HALF-SETTLED. Both probes measured; both found defective; neither usable as-is." My decision on 27 July was repair both, don't pick a winner — because each one is sound exactly where the other fails.

To what extent is it usable, honestly

What I am doing with them now

I froze a three-dial repair declaration before touching any code, so the fix can't be tuned to taste:

• Dial 1 — extend the rotational probe's panel hygiene to legacy, so price levels and trade IDs stop acting as redundancy drivers.
• Dial 2 — make PASS two-dial symmetric with BAN. B_pass = 0.20 frozen; the panel-R² band anchored to P₅₀ of the shipped columns, k=50 frozen. Measured: P₅₀ = 0.9259 over n=66. Falsifiability check passes — l_kurtosis_tau4 (0.9142) now clears it, so the new band is not vacuous.
• Dial 3 — suspend the sibling LOO-R² leg from verdict authority until it is re-scaled.

3.2 · Instrument grounding — the campaign that finished Complete

It ran across the week — the laptop-drives-bigblack loop harness on Wednesday (#655), a SEAL-PASS cycle the same day (#657), cycle 2 on Thursday (#658), and closure on Friday (#661).

3.3 · The evaluation framework — what we are building and why

It reconciles three strands of work that had been running separately — the forward-predictiveness measurement stack, the realness/usefulness instruments, and the new cascade-free candidate harvest — into a single funnel with two named axes:

What we have done so far

• The graders are validated. The realness instrument-grounding campaign in §3.2 closed at 20/20 terminal — 19 GROUNDED, 1 REJECTED. Those are the measuring tools, proven before use.
• The candidate cohort is harvested and frozen. Six iterations (#656, #659, #662) produced 120 candidates across order-flow toxicity, systemic fragility, jump/tail ignition, illiquidity and price impact, crypto liquidity integrity, and order-book depth. Zero duplicates across all six — so the space is not yet saturated.
• The rulebook is frozen. Phase 0 pre-registration landed Friday (#664): every gate, threshold and control fixed before any candidate was measured.

How we plan to run it

Cheapest filters first, so the most candidates die for the least compute. Default is EXCLUDE — a candidate advances only by clearing a gate. One gate per loop firing.

Frozen thresholds: F2 BAN at max|ρ| > 0.95 · F3 retention R ≥ 0.5 · F4 null FPR ≤ 0.05, BY-FDR at q = 0.10, PBO ≤ 0.2, power ≥ 0.80 · F5 k-of-N binomial exceedance at α = 0.05.

The page that describes how we evaluate features

The methodology above is published as a live page — the question, the trap, the funnel, the rules that cannot be bent, and an append-only ledger that fills in as gates fire:

findings/dashboard/probes/2026-07-24-axis2-cascade-free-evaluation/index.html
  → odb.epatner.com/opendeviationbar-py/dashboard/probes/2026-07-24-axis2-cascade-free-evaluation/

The narrative overview that sets up both axes in plain English, if you want the thesis before the mechanics, is probes/regime-invariant-orthogonality-campaign-2026-07-22.html ("Orthogonality Direction — Design Preview").

One housekeeping note: neither page is currently linked from the dashboard hub, site-map, or probes index, so they are reachable only by direct URL. My own check-orphan-pages.py is what should have caught that, and I am regenerating the nav.

3.4 · Cost-realism label backfill — hardening

The label_fwd_3s_* family is what makes the honest-cost numbers in §1.2 possible. The kernel itself landed earlier in July; this week was the hardening pass after the first real production run.

3.5 · Where candidate coverage actually stands

Context for §3.1 and §3.2, because "110 candidates in the registry" reads far more complete than it is:

By orthogonality verdict: 88 null · 12 PASS · 5 BAN · 4 WATCH · 1 PENDING. Of the 88 unresolved, 13 are runnable today, 9 need only a reuse-confirmation, and 66 need a kernel implemented before they can even be tested. After batch-02 there were 3 runnable candidates left in the queue. The machinery is considerably further along than the coverage — and per §3.1, the gate that would resolve the rest is currently the thing that's broken.

4Validation machinery — built vs actually run

I want to be precise here, because "we built a CSCV-PBO module" and "we have a PBO number" are very different claims and it would be easy to blur them.

Reference — the failure-mode catalog

Every verdict in this report cites one of these. The catalog started at 10 codes, now stands at 13, and grows toward the 29-bucket canonical inventory in the patterns repo. Worth noting that FM-13 was minted and then withdrawn during the PR-#7 adversarial pass — its diagnostic turned out to be a worst-fill artifact — and later re-grounded on Brunnermeier–Pedersen (2009). The catalog gets falsified too.

Source of truth: research-audit/failure-modes/README.md (not the top-level README, which only links to it).

5What I plan to do next

5.1 · Other work in flight

Besides the cross-sectional run in §1.3, which is the main one:

The eight correctness PRs on the research repo (#32–#41) all landed Monday night, so that queue is clear.

5.2 · The order I intend to take them in

1. Write the data-access mini-ADR and run the cross-sectional sieve. The machinery from §1.3 is finished and tested; the ADR is what stands between it and real data. This is the main line because it attacks the exact mechanism that killed all 616 rules.
2. Close the provenance gap. The five slices behind the 600-rule result have no data/PROVENANCE.md entry and live on bigblack rather than in the repo, and the BTCUSDT 15-feature slice has no SHA256 recorded anywhere. Backfilling it is cheap, and until it is done the result is documented but not reproducible from repo contents.
3. Fire the SEAL gate on the Axis-2 cohort. 120 candidates are frozen and the rulebook is fixed. The self-test comes before any real candidate, so that is the next firing.
4. Get R2 to complete on the probe repair. The three dials are frozen but the validating re-run died on a ClickHouse memory limit, and the resource envelope needs fixing properly — the server side was never actually capped. Until R2 lands, axis.orthogonal cannot be set and 78 unevaluated candidates stay where they are.
5. Hold the subordinator work at its current size. It is days old and I am not letting it grow until it has been weighed against the crypto panel.

5.3 · Where your perspective would be useful

Nothing here is waiting on a decision from you — the list above proceeds either way. But there are three places where your read would genuinely change what I do, and this is the natural point to raise them.

6How to verify any number in this report

Every figure here traces to a committed artifact. The primary sources, in order of authority:

Reproducer for the main campaign, per symbol

uv run python scripts/enumerate_sieve.py --all-features \
  --data data/<SYMBOL>_250dbps_15feat.parquet \
  --out research-audit/loop-runs/enumerate-sieve-<SYMBOL>-250-15feat.json \
  --table research-audit/loop-runs/enumerate-sieve-<SYMBOL>-250-15feat.md

Runs on bigblack under a 5-core / 5 GB hard cap (systemd-run --user --scope -p CPUQuota=500% -p MemoryMax=5G -p MemorySwapMax=0); peak RSS ≈ 1 GB, 3–6 min per symbol. Note the provenance gap flagged in §5 — the input slices live on bigblack, not in this repo.