~940 signals/year: how keel went from 2 trades per asset-year to a collectable evidence pipeline (Coinbase spot)

[eaitbrahim]

The number

~940 entry signals per year, pooled across 19 assets (~2.6/day). Six weeks ago the same engine, on the same venue — Coinbase spot, USD pairs, the only venue keel trades — produced 2.15 signals per asset per year.

The problem it fixes

keel's promotion gate demands n=100 trades per rule per product before paper evidence can argue for real money. At 2.15 signals/asset-yr that gate is 31–84 years away per asset. As the August status review put it: waiting is not a slower path; it is no path. The engine's honesty gates were fine; the clock was the defect.

How it was achieved — three moves, each measured

1. Trade the same rules on an hourly clock (issue #337). The daily turtle rules evaluated on ONE_HOUR bars fire 49.4 signals per asset-year (measured over 5 years of cached Coinbase candles; median n=268 per rule-product; range 48.5 LTC to 57.0 BTC) — a 23x increase with zero parameter changes. This shipped as a third deployment profile, paper-hourly: its own database, its own config, one cycle per UTC hour, kill-switch-gated.

2. Fix the warm-up so the confirmation series actually exists (issue #349, shipped in v0.9.1). The documented cache-warm step turned out to fetch only two of the profile's three candle series — keel fetch was ignoring config.market_data.granularities, so the FIFTEEN_MINUTE entry-gate confirmation series started with literally one bar per product. v0.9.1 makes every fetch path honor the config; the warm step now fills ~35,000 fifteen-minute bars per product.

3. Widen the universe 8 → 19, behind a measured health gate (issue #351, PR #358). Eleven Tier-2 assets (ZEC, NEAR, AVAX, UNI, FET, ICP, DOT, CRV, ALGO, BCH, DOGE) were admitted only after a 90-day FIFTEEN_MINUTE data-health screen on Coinbase: coverage >= 95.98%, zero zero-volume bars, worst gap 5 bars. They trade with target weights capped at 2% each (78/22 Tier-1/Tier-2 split) pending the spread-gate rail (#350).

49.4 signals/asset-yr x 19 assets = ~940/year. The n=100 pooled forward-trades review (#353) is now ~5-6 weeks of accrual away, not decades — it is scheduled for 2026-09-30.

The honest caveat (read this part)

The hourly configuration is measured NET-NEGATIVE at Coinbase's taker fees — 0 of 90 backtest cells profitable at every fee tier the venue offers (restated 2026-08-13 under the production-faithful engine). This pipeline exists to produce admissible forward evidence — rail vetoes, real outcomes, pending lifespans, intent divergence: the things a backtest cannot observe — not profit. A positive stretch would prove nothing: ~250 sequential trades inside one regime are not 250 independent draws. Daily-tuned parameters on an hourly clock is also, legitimately, a different strategy; forward evidence is the only thing that can settle it.

Status

The kill switch on the hourly profile was opened by the operator on 2026-08-18; the first 19-asset cycle ran clean (19 rules evaluated, correct no-signal verdicts, no errors). Progress tracks in milestone 14; the n=100 review lands in #353.

[eaitbrahim]

Correction for everyone signed up for the 2026-09-30 pooled review: the n=100 floor carries about 39 independent observations, and on that sample the review can only see an edge of 20 points or more.

This discussion scheduled the review at a floor of n=100 pooled trades, and the announcement reads that floor as 100 observations. They are not independent: the signals fire in herds (about 8 assets the same UTC day, largest episode 24) and the outcomes correlate within an episode (ICC 0.212). That is #427, measured against this discussion's own published rates (the reconstruction reproduces 49.4 signals/asset-year and median n=268 within a few percent). The correction is now executable in keel/research/throughput.py and pinned by tests/research/test_throughput.py:

quantity	value
design effect (k = 8.43, ICC = 0.212)	2.58
n_eff at n = 100 pooled	39
detectable edge at 80% power, one-sided 5%	20.0 points (12.4 if the trades were independent)

to detect	n_eff needed	pooled trades needed
12.4 pts	101	259
10 pts	155	399
7.5 pts	275	708
5 pts	619	1,593
— what "n=100" was assumed to deliver	100	258

What 100 pooled trades can and cannot show on 30 September. They cannot show whether the rule has an edge in any range the backtest admits as plausible: detecting an edge at 80% power would need a win rate around 41%, against a reconstructed 14.9%. The review is near-certain to return "no edge", and that is the correct answer — but the write-up must not say "we measured no edge at n=100". The honest statement is "at n=100 pooled this test can only see an edge of 20 points or more." Those read the same and mean very different things.

Recommendation (decision stays with @eaitbrahim as the review's owner): reframe the 2026-09-30 review as descriptive rather than a pass/fail gate. The break-even arithmetic in the cross-verification note (§5) is what fixes the edge worth powering for: inside the fee-free allowance the break-even win rate is 14.88% against a reconstructed 14.9% — the plausible edge at the fee actually paid is within half a point of zero — and outside the allowance the rules are 14 points underwater, which no detectable edge rescues. Powering for the only regime worth trading means powering for a small edge: 5 points needs 1,593 pooled trades (~50 years at Basic hourly throughput even after the #426 fix), and even the minimum honest floor of 258 pooled only detects 12.4-point edges, which the reconstruction says do not exist. So on the scheduled date the review should report forward outcome rates with n_eff-corrected intervals (keel/research/significance.py), rail-veto telemetry, and accrual vs the ~2.6/day expectation — with the sentence "at this n_eff the review can only see an edge of X points or larger" printed in the report itself. If a confirmatory floor is wanted, 259 pooled (= n_eff 101, what "n=100" was believed to mean) is the entry bar, and 1,593 is where 5-point edges become visible.

Corrections of record: the roadmap PRD (docs/superpowers/specs/2026-08-21-v0.11-plus-roadmap-prd.md), the glossary's promotion-gate entry, and the cross-verification note §4.1. Tracking in #427; the review itself lands in #353.