mmsell: entry-timing study, on the right clock per settle mode

[50thycal]

What it answers

Does WHEN we enter matter? Measured on our own book: 10,337 in-play trades across 3,783 distinct markets, vs the 1,137 h2h entries the original U-shape backtest was built on.

The finding that shapes the whole design

hours_to_close — the obvious timing variable — is valid for scheduled/discrete markets and a fiction for in-play ones. Kalshi sets a sports market's close_time to a far-future fallback, not the end of the contest:

mode	avg htc at entry	avg actual time to resolution	gap
in_play	145.9h	2.0h	143.9h
scheduled	44.8h	46.8h	−2.0h
discrete	63.4h	55.9h	7.5h

Per series it's worse — KXUFCFIGHT reads 335h-to-close on a fight that resolves in 0.4h, pinned at our own htcmax=336 cap. Bucketing in-play trades by hours_to_close files every one under "24–72h" and measures nothing while looking perfectly healthy. So the study uses a different clock per mode and prints the validation table first on every run, as a guardrail against anyone switching it back.

Two consequences beyond the bucketing:

• The global mmsell_min_hours_to_close = 1.0 floor never binds on sports at all — the books already enter deep in-play (0.4–1.5h of contest left) with no rule saying so.
• A live in-play timing gate is impossible until the worker persists a forward-looking field (expected_expiration_time).

Result — the endgame half of the U-shape replicates

window	n	mkts	¢/trade	edge
<0.25h	588	223	+8.85	+11.4
0.25–0.5h	1318	588	+6.72	+7.3
0.5–1h	2079	1010	+2.28	+2.4
1–2h	3488	1565	−1.55	−1.6
2–4h	2317	916	+1.77	+1.9
4–12h	283	121	−4.28	−4.5

It was the half predicted most likely to be a mirage, and the largest single cell (1–2h, n=3,488) is the one losing money.

h2h is the sharpest read: +8.97¢ in the final 15 minutes against −13.34¢ beyond 12 hours. docs/MMSELL_MARKET_TYPES.md scored h2h at +0.63¢ pooled and called it the weakest large in-play type — that number was averaging those two ends. h2h is not a bad type, it's a badly-timed one.

total and spread behave the same way. player_prop and outright do not (they peak at 0.5–1h and 2–4h/12h+), which is why the per-type cut exists — the pooled shape does not generalize.

Caveats, documented and gated on

1. Long-game confound (the serious one). Hold time is entry→resolution, so a game that runs long lands in a later bucket — and games run long when they're close, which is exactly where a cheap tail is live. Some share of the gradient is "blowouts end on schedule" rather than "late entry is safe". This is the main reason a forward-looking field is needed before promoting anything.
2. Detection lag — the in-play clock is measured at settlement detection, so the bias bites hardest in the shortest cell.
3. Fill-everything paper. The endgame is a thin, fast book: precisely where a resting maker is picked off. Both prior timing signals died exactly there (mmsell7 htcmax=24 was its cohort's worst; mmsell11 htcmin=6 went +2.38¢ paper → −0.86¢ realizable). Nothing here is promotable until it clears mmsell fill model.

Pre-registered gates for a .timeX book are in docs/MMSELL_TIMING_STUDY.md: edge ≥ +3.0pp above the adjacent window at n ≥ 300 and ≥ 150 distinct markets, holding within a single type, plus positive realizable ¢/trade.

Notes

Taxonomy and per-cell statistics are imported from scripts/mmsell_market_types.py rather than re-declared, so a type cannot mean one thing in the census and another here. Read-only, self-contained; the only non-script edit is the ALLOWED_SCRIPTS entry.

Testing

tests/test_mmsell_timing_study.py — 7 tests pinning the per-mode clock mapping (the finding itself), lower-bound-inclusive bucketing, grid well-formedness, that a missing or impossible clock value drops out as coverage loss rather than flooring into the shortest bucket (where it would manufacture exactly the late-entry edge under test), and that the taxonomy is imported rather than copied. Full suite green. Script has been run end-to-end against the live DB via the ops channel.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ECFY4eoPk2g1JUanmFqkee

---

Generated by Claude Code