Framing the job

The goal in plain terms: make Edge-Radar's expected value per dollar staked positive and repeatable, not lucky. A good result here is a markdown doc that (a) states what the settled record actually proves, (b) separates the knobs that have evidence behind them from the ones that are folklore, and (c) gives Mike an ordered list of changes where each one names the file, the config key, and the measurement that would tell us it worked. Anything that reads "consider tuning X" without a threshold is not an action item.

I ran my own pass over data/history/kalshi_settlements.json (402 settles, 2026-03 → 2026-08), kalshi_trades.json (169 rows), CLAUDE.md, and the gate/sizing code. Here is my first real contribution — five findings, three of which I think reframe the problem.

1. The system is not profitable. Five bets are.

Headline: +$54.04 net on $381.66 staked, +14.2% ROI, 46.5% win rate. Looks great.

Strip the five largest winners and it is −$8.15. Strip the top three and it is +$8.27 on $382 — noise. The top four by P&L:

Three of four are sub-10c MLS spread longshots. The whole sub-10c band is 25 bets, $20.35 staked, +$25.83 — and every dollar of it is those three tickets. 22 of 25 lost. That is not an edge, that's a 12% hit rate on 15:1 shots inside a 25-bet sample.

So the first thing the doc has to say: the current record cannot distinguish "we have a +14% edge" from "we are break-even and got lucky three times in eight weeks." Every recommendation downstream has to respect that.

2. The regime already flipped, and nobody has acted on it

Last 90 days: −13.8% on 129 settles. And it is not just the NO side that F4 already damped — in that window YES is −16.2% and NO is −11.5%. SPREAD went from +36.6% lifetime to −28.2% recent; TOTAL from +2.2% to −13.3%. The bleed is broad, which points at the model, not at one bad population.

3. Claimed edge is anti-correlated with realized ROI above ~12%

Bucketing by edge_estimated:

The biggest claimed edges have the worst win rate in the book. This is F3's λ=0.16 showing up from a completely different angle, and it has a sharp operational consequence the current config does not implement: the gates only have a floor on edge. There is no ceiling. A row claiming 40% edge sails through Gate 3 and gets Kelly-sized off a number the settled record says is mostly fantasy. KELLY_EDGE_CAP=0.15 damps the size but the bet still gets placed.

4. Fees are eating a third of the edge floor and were invisible until last week

Total fees $11.97 on $381.66 = 3.1% of stake, against a global MIN_EDGE_THRESHOLD=0.03. F1 landed 2026-08-25 and folds the fee into the Gate 3 floor and Kelly — correct, and it means every pre-2026-08-25 number in this analysis, including the +14.2%, was screened on gross edge. The historical record was generated by a looser filter than the one now running. Worth saying out loud in the doc.

5. The measurement gap that I think is the actual top priority

clv is populated on 0 of 169 trades, despite closing_price being present on 76 of them. Nobody is computing closing-line value.

That is the whole ballgame. With median stake $0.80 and P&L concentration this extreme, outcome ROI needs ~2,000+ settles to say anything — we have 402 and it took five months. CLV converges on the order of 10–50x faster because it scores the decision instead of the coin flip. A system that consistently beats the close is profitable eventually even through a losing quarter; one that loses to the close is not, no matter what March looked like.

What I want to argue for, and where I want pushback

My position: the path to "maximize positive betting revenue over time" does not start with a new sizing knob. It starts with making the feedback loop fast enough to tune anything at all. Order I'd put it in:

1. Backfill and log CLV (closing_price is already captured for 45% of trades — the plumbing half-exists).
2. Add an edge ceiling gate — reject or heavily shrink rows claiming >~15–20%, since the data says those are model failures, not opportunities.
3. Shrink the surface to where there is evidence: MLB is −6.4% lifetime and −10.3% recent on the largest book ($161 staked, 40% of everything). NBA is −23.3%. Both are running.
4. Re-decide the sub-10c lane on purpose. MIN_MARKET_PRICE=0.10 is flagged in CLAUDE.md as an open experiment; my read is that it is a variance pump that happens to have paid, and it should either be sized down hard or shut off — but I hold that loosely, because if the model has any real signal it is on cheap contracts (F3 says exactly that: ≤32c high-edge beats low-edge by +10.8 pts).

Two things I want you to attack specifically:

• Is #4 wrong? F3's own evidence says the model's only real signal is on cheap contracts. If so, killing the longshot lane kills the one place the edge is real, and the right move is the opposite: keep it, cap the stake per ticket, and stop counting it as proof of anything.
• Am I over-reading the regime break? Jun–Aug is 128 settles. Is −13.2% actually distinguishable from the same distribution that produced +32%, or am I doing exactly what I just accused the headline number of doing — reading noise as signal?

Give me your independent read before you react to mine. If you found something in the wager scripts, the backtester, or the Polymarket path that I skipped, that is more useful right now than agreement.

I ran your λ-multiplier against the ledger before replying, and it does something neither of us predicted. Also: one of my five findings was wrong in a way that changes your action item #2. Taking those in order.

Correction first — CLV isn't missing, it's broken

I said "nobody is computing closing-line value." Wrong. kalshi_settler.py:320-334 computes it on every settle. Here's the actual state:

trades with closing_price: 76 / 169
distinct values of closing_price: {0.0: 76}      <-- all of them
trades with clv: 0
settlements with closing_price: 150, clv: 0

The bug is at line 326: closing_price = float(market_data.get("last_price", 0)) / 100, read from the market snapshot at settlement time. A settled Kalshi market has no meaningful last_price — the field comes back 0 or absent, so closing_price is 0.0, which is falsy, so line 334's if closing_price and entry_price short-circuits and clv is None. Every single time, silently, for five months.

So your action item 2 — "backfill CLV from existing closing_price" — can't run. There is nothing to backfill; the column is 150 zeros. CLV requires a new capture: snapshot the market price at event start (or T-5min), store it on the trade row, and compute CLV against that. That's a scheduled job that doesn't exist, not a backfill. It changes the cost of the item from an afternoon to a small feature, and it means CLV data starts accruing from the day it ships, not retroactively — which matters a lot for sequencing everything else.

Your λ-multiplier vs my edge ceiling — I ran both

Replayed all 390 settles with edge_estimated, applying λ·edge ≥ floor + fee(price) as the Gate-3 test:

Two things fall out.

One: at λ=0.16 with the floors left where they are, you keep 44 of 390 bets — 11% of the book. With the fee added at a 50c contract the effective bar becomes edge ≥ 0.29. That is exactly the ≥20% claimed-edge population I flagged as the worst-performing bucket in the book (34.8% win rate). λ-scaling with a fixed floor doesn't correct overstatement — it selects for it. It hands you a 44-bet-per-5-months portfolio composed entirely of the model's most confident hallucinations. The +12.2% on those 44 is $4.78 on $39 and I would not spend a dollar on it.

Two, and this is the part I'd ask you to sit with: λ is a monotone transform. Multiplying every claimed edge by a constant and then thresholding just slides the cut along an unchanged ranking. If you drop the floor proportionally (λ=0.16, floor 0.0048) you keep 141 bets at +27.9% — but that's the same ranking, cut at a different place. A multiplier cannot repair a relationship that isn't monotone, and the bucket table says ours isn't: it rises to 8–12% and then falls off a cliff. You need a non-monotone operator for a non-monotone defect. That's what a ceiling is. So I don't think we're choosing between them — λ sets how much to trust, a ceiling handles where trust inverts, and they're orthogonal.

But here's the thing that made me stop arguing about either of them:

The band we'd both keep is the band that's bleeding

Filter to claimed edge in 5–15% — the pocket both our proposals converge on:

lifetime:  n=229  $215.76 staked  +$35.93  +16.7%
Jun-Aug:   n=88   $112.61 staked  -$22.58  -20.1%

The "good" band is down 20% over the last three months on half the sample. So is SPREAD (+36.6% → −28.2%). So is TOTAL (+2.2% → −13.3%). So is YES (+30.8% → −16.2%), which F4 didn't touch. Every slice we would carve out on lifetime numbers is losing on recent numbers. That's not a selection problem you fix by re-cutting the same ranking. It says the ranking itself decayed, and a static gate tuned on Mar–May data is a gate tuned on a distribution that no longer exists.

On my own significance question, which I asked you and should answer myself: permutation test on the Mar–May vs Jun–Aug ROI gap gives p = 0.018 one-sided (20k shuffles). Real enough to act on, and I'll flag the multiple-comparisons caveat in the doc. But the number that actually matters is this one — bootstrap 95% CI on lifetime ROI, 10k resamples:

+14.2% ROI, 95% CI [−6.2%, +36.8%]. It contains zero. And my "8–12% is the sweet spot" claim from turn 1 — CI [−12.4%, +84.7%]. I over-sold that. The direction agrees with F3's independent λ estimate, which is why I still believe it, but it is not on its own evidence.

Where I think we actually agree, stated as decisions

I want to lock these so we stop relitigating them:

1. No size increase, full stop. Lifetime ROI CI includes zero. KELLY_FRACTION ≤ 0.5 stands.
2. CLV is P0, but as a new capture job plus a settler bug fix, not a backfill. Nothing else can be measured properly until it lands.
3. λ-scaling and an edge ceiling both go in, and both go in shadow mode first — logged as trusted_edge and gate3_ceiling_would_reject, changing no live decision, so we can see how often they fire against live rows before they cost us anything.
4. Your two operational findings are the highest ROI-per-hour items in the whole list and I'd promote both above the strategy work. The Nevada jurisdiction rejections are pure waste — the executor is burning API calls and scheduler cycles on rows that are structurally unfillable. And the .env-vs-.bat-vs-import-time-snapshot trap is worse than a footnote: it means we could ship every recommendation in this document and have zero of them reach the live automation. Every action item needs a "how do I verify this is actually live" line.
5. Polymarket stays a lab. 54 executable rows across 45 runs, all failing on edge, zero settlements. Agreed: don't loosen a gate to manufacture a trade.

What I want to open next

We've both been optimizing the numerator. "Maximize positive betting revenue over time" is edge × turnover, and turnover here is $382 across five months on a ~$92 bankroll, median stake $0.80. Even a genuine, durable +10% edge returns about $38 in five months. That's the ceiling on this entire exercise as currently configured.

I'm not proposing we scale — the CI says absolutely not. I'm proposing the doc name the trigger in advance, so the decision isn't made emotionally after a hot week: e.g. mean CLV > 0 across ≥150 trades with the lower bootstrap bound above zero, sustained 60 days → then and only then raise UNIT_SIZE/KELLY_FRACTION, one knob at a time. Otherwise this becomes a document about how to lose less, and the goal Mike set was to make money.

Two questions back at you:

• Is a static gate the wrong shape entirely? Given every slice decays, should the per-sport floors be rolling — computed from a trailing 90-day window and auto-widened when a sport's recent CLV goes negative — rather than constants in .env that someone remembers to tune? That's a real architecture change and I want it challenged before it goes in the doc.
• What's the kill criterion? If CLV lands and reads negative across the board for 90 days, what does the doc tell Mike to do? I think it has to say "stop betting real money and run dry-run only," and I'd rather we write that sentence now, while nothing is at stake, than discover we never wrote it.

Your hybrid is right and I'm adopting it — "rolling state may only tighten" is the constraint I was missing, and it kills the overfit-to-a-hot-slice failure I would have walked straight into. strategy_state.json written by analysis, read at the risk boundary, timestamp echoed by doctor.py: that's the design. Locked.

Now I need to break two things in your example state, and put a live exposure on the table that neither of us has mentioned.

1. sport:NBA → dry_run is a no-op, and the same trap is under half our recommendations

Last settled bet per sport:

NCAAMB   2026-03-22 .. 2026-04-02   (n=56)
NBA      2026-04-05 .. 2026-06-14   (n=32)
NHL      2026-04-05 .. 2026-06-15   (n=60)
WC       2026-06-21 .. 2026-07-15   (n=43)
MLB      2026-03-29 .. 2026-08-05   (n=143)
MLS      2026-04-11 .. 2026-08-20   (n=64)

Today is 2026-08-26. NBA, NHL, and NCAAMB are out of season. Demoting NBA to dry-run costs nothing and buys nothing — it will read as an action taken while changing zero behavior, and when the season opens in October the demotion will still be sitting there enforcing a policy derived from a 32-bet sample settled five months earlier. Same for "keep NHL because lifetime ROI was +62%."

So the state file needs a staleness rule, not just a tightening rule: a segment's execution status expires N days after its last settled bet and reverts to a declared cold-start default. Otherwise strategy_state.json becomes a graveyard of decisions about seasons that ended.

And the cold-start default matters more than any of the in-season policy, because:

2. The live book is 24 open NFL positions and there is no NFL history at all

This is the finding I want in the doc above the statistics. Reconciling kalshi_trades.json against kalshi_settlements.json by trade_id:

open positions: 24     cost: $28.50     oldest entry: 2026-05-23
  KXNFLTOTAL   n=11   $14.96
  KXNFLSPREAD  n=10   $8.68
  KXNFLGAME    n= 3   $4.86
NFL rows in settlements: 0

Plus 6 status='error' NFL rows and 2 resting. Every one is live money, dry_run=false.

Three things about that:

• $28.50 open against a ~$92 bankroll is 31% of the account, concentrated in one sport, held up to 95 days before the games are played. MAX_OPEN_POSITIONS=50 and MAX_PER_EVENT=2 both pass — neither gate measures total capital deployed, and there is no gate that does. That's a structural hole: you can satisfy every one of the nine gates and still have a third of the account parked in September football since May.
• NFL has zero settled bets in the entire ledger. Every number we've argued about — λ, the price bands, the edge buckets, the regime break — comes from MLB/MLS/NHL/NBA/NCAAMB/WC. The system's largest current position is in a sport with no calibration evidence whatsoever. Its margin_stdev of 13.5 in data/cache/calibration_stdevs.json is a hardcoded prior, not a fit — unlike baseball_mlb: 4.025 and icehockey_nhl: 2.5, which carry the decimals of something actually computed.
• The .env L2 comment already tells us what this book looks like: the 2026-08-18 NFL Week 1 audit found 13 of 27 open positions past the 5c spread line, up to 20c wide, and 18 of 27 with zero 24h volume. Those positions were opened before Gate 3.6 existed. So the current open book was selected by a filter that let through exactly the illiquid rows the new gate was written to stop — and Gate 3.6 only runs at entry. Nothing re-checks a position already held.

Decision I want to put to you: does the doc tell Mike to flatten the pre-L2 NFL book, or hold it?

My position: hold, but stop adding. Flattening 24 illiquid positions into 5–20c-wide books pays the spread twice and crystallizes a loss on a sample too small to prove anything — you'd hand back real money to escape a paper problem. But MIN_EDGE_THRESHOLD_NFL=1.0 (the F3 World-Cup idiom) until the season produces settled, CLV-measured evidence is nearly free, since the alternative is opening more positions in the one sport we have no evidence on, sized off an unfitted stdev, through a book we've documented as illiquid. Argue me out of it if you think the spread cost of exiting is smaller than the tail risk of holding — I could be wrong about which side of that trade is cheaper, and I don't have the current asks.

3. Every profitable sport is a concentration artifact too

One more number, because it kills the "keep NHL/MLS" half of the pruning plan the same way it killed the headline:

MLS's entire reputation is three sub-10c spread tickets. NCAAMB flips sign. There is no sport in this ledger with a defensible positive ROI once you remove three bets from each. So the doc cannot say "keep the winners, cut the losers" — there are no winners, only sports that have and haven't been lucky yet. The honest cold-start default for every segment is the same one, and the only thing that will ever differentiate them is CLV.

Where we stand

Agreed and closed: hybrid tightening-only state file · CLV as new capture in bet-side probability space, T-5min, never settlement last_price · λ as a logged diagnostic not a live gate · ceiling shadow-first at 0.20 warn / 0.30 reject · your three-phase framing (stop waste → prove EV → scale) · kill and promotion thresholds roughly as you wrote them.

Two I want to sharpen before I write it up:

• Your global kill needs a time bound as well as a count. "150 captured bets" at the current rate is roughly two months in season and never in February. I'd add: or 120 days elapsed with fewer than 150 captures, in which case the segment goes dry-run for insufficient evidence rather than waiting forever. Silence should default to off, not to running.
• Total-exposure cap. I want MAX_OPEN_EXPOSURE_PCT (say 20% of bankroll, gate 2b, alongside the position count) in the action list, on the strength of the 31% NFL number. Do you see a reason the batch-median MAX_BET_RATIO and the --budget 10% flag already cover this? I don't think they do — both bound a single scan, and this book accumulated across roughly a dozen scans over three months.

I have two turns after this one. Next turn I want to settle the NFL flatten/hold question and the exposure cap, then I'm writing the artifact.

Agreed on all of it — hold-not-flatten, the legacy-position quarantine so the pre-L2 book can't be used to validate or condemn the post-L2 system, MAX_OPEN_EXPOSURE_PCT=0.20 + MAX_SEGMENT_EXPOSURE_PCT=0.10, MAX_DAYS_TO_EVENT_FOR_GAME_MARKETS=14, and your four-state evidence_status. Your distinction between dry_run: insufficient_evidence and dry_run: negative_clv is better than my blanket kill and I'm taking it as written. Your seven-item ordering is the spine of the artifact.

So the plan is done. Before I write it up, I want to put one thing on the table, because I don't think the plan as it stands can reach the goal Mike actually set — and I found the reason in the fee column.

Every order in this system is a taker, and that alone is bigger than the edge

maker_fees nonzero:  0 / 169 trades
taker_fees nonzero: 17 / 169
fees:  $11.97 on $381.66 staked = 3.14% of stake
ROI with fees: +14.2%   |   ROI if fees were zero: +17.3%

Now put that next to F3. If λ = 0.16, then a row claiming a 10% edge — comfortably above every floor in .env, the middle of the band we both wanted to keep — carries a trusted edge of 1.6%. Against a 3.14% realized fee drag.

The system is structurally negative-EV as a pure taker, and no amount of gate tuning fixes that. Every action item we've written — the ceiling, the exposure caps, the state file, the CLV loop — makes the system lose less. None of them changes the sign. You can select perfectly from a distribution and still lose if the toll to enter exceeds the prize.

Here's what makes this actionable rather than depressing: Kalshi maker fees are zero, and the client already places the right kind of order. kalshi_client.create_order() takes yes_price_cents / no_price_cents with time_in_force="good_till_canceled" — these are limit orders that can rest. They just never do, because the executor prices them to cross. Confirmation is in the fill data: 140 filled, 5 resting, and maker_fees is "0" on every single row — not "we earn no rebate," but "we have never once been the passive side."

So there's a lever nobody has pulled: post at the bid instead of lifting the offer. ceil(0.07 · C · P · (1−P)) becomes $0. On the settled book that is $11.97 recovered on $381.66 — a +3.14 percentage-point swing in ROI that requires the model to be no better than it is today. It's the only item in this entire conversation whose payoff doesn't depend on Edge-Radar having skill.

The cost is real and I'm not hiding it:

• Fill risk. A resting bid fills only when someone crosses to you, so you get partial or zero fills. RESTING_ORDER_MAX_HOURS=24 (R4) already exists to cancel stale ones, so the cleanup machinery is built.
• Adverse selection — the serious objection. Your resting bid fills preferentially when the market is moving against you. That is a genuine cost that partly offsets the 3.14%, and I can't size it from this data.
• It only works in a liquid book. On the 5–20c-wide NFL spreads the L2 audit found, there is no bid to sit on. Which is a neat argument that Gate 3.6 and a maker strategy are the same policy from two directions: both say only trade where a real two-sided market exists.

And here's why it fits our own framework rather than fighting it: CLV measures this directly. A maker fill at the bid has, mechanically, better entry than a taker fill at the ask by exactly the spread. If the maker strategy's adverse selection is worse than the fee it saves, mean CLV on maker fills comes out below taker fills, and the experiment kills itself with the instrument we're already building. It's the ideal Phase-2 A/B: route half of qualifying orders as passive at the bid, half as today's aggressive, and compare mean CLV plus fill rate after 100 orders each. No new measurement, no new risk beyond unfilled orders, and the result is legible either way.

My claim, plainly: the doc's Phase 3 cannot be "scale turnover once CLV is positive," because at λ=0.16 there may be nothing to scale. Phase 3 has to be "remove the structural cost of trading," and the maker experiment is the first item in it. Scaling comes fourth, if at all.

Tell me where that's wrong. The place I'm least sure is adverse selection — if you think passive fills on Kalshi sports are systematically poisoned enough to eat the whole 3.14%, say so and I'll write it into the doc as a risk with the A/B as the resolution rather than as a recommendation. What I'd resist is leaving it out: a plan that only knows how to lose less isn't the plan Mike asked for.

Next turn I write the artifact.

All four accepted, and two of them change the design rather than the wording — worth saying which.

Close-book snapshot (your #1): accepted, and it fixes a hole I had left open. My spec wrote a scalar and would have made the maker A/B unreadable. If a maker order rests at the bid and fills there, and the close is scored off last_price, the fill and the close are sampled from different sides of the book — the measured "maker CLV advantage" would be partly a bid-vs-ask artifact. Storing close_yes_bid/ask, close_no_bid/ask, close_mid_bet_side, close_capture_at, close_capture_reason lets the A/B be re-scored on mid, on same-side, and on cross-side, and report all three. That is the difference between a number and an argument.

One addition to your capture spec, because it is exactly how D1 happened: missed must be null, never zero. The original bug was a falsy sentinel silently absorbed by an if closing_price and ... guard. If a T−5min job misses a market and writes 0.0, every CLV mean gets dragged toward a fictitious −entry_price. So: close_capture_reason='missed' ⇒ clv IS NULL, excluded from every mean, and capture coverage is itself a reported metric — mean CLV over 60% of the book is not the same claim as mean CLV over 97% of it, and if coverage is low and non-random (misses concentrated in illiquid markets, which is where the bad bets live) the mean is biased optimistic. The report prints n_captured / n_settled beside every CLV figure.

Nevada / fail-closed (your #2): accepted, and you are right that I underrated it. I filed it as waste; it is a correctness bug. unknown eligibility ⇒ dry_run is the correct default, and note what it implies: if the account genuinely cannot trade Sports on this venue, then a large fraction of the entire book is unreachable, and the operator needs to know that on day one rather than discovering it as a slow trickle of rejects. Cache at startup, print in doctor.py, fail closed, and add the eligibility line to the daily summary so a silent change of status is visible.

#3 and #4: taken verbatim. 1.1 now reads as a temporary freeze mechanism with an explicit exit — MIN_EDGE_THRESHOLD_NFL=1.0 comes out when strategy-state cold-start/pilot exists, and 2.3 is named as the thing that replaces it. An impossible threshold left in .env after the evidence system ships is a landmine, and it is exactly the class of stale-config bug D4 already describes. Docs index link added as 1.8.

New ground, and it is the one thing neither of us has written down: what the operator actually looks at. Every mechanism in this plan is invisible unless it surfaces daily. The Phase 2 daily summary should carry six lines and no more:

1. eligibility: kalshi/sports OK | UNKNOWN→dry_run
2. effective config hash + whether it matches .env (D4, made visible instead of audited once)
3. open exposure: $X (Y% of bankroll) — legacy $Z excluded
4. CLV last 30d: +A.A pts [CI], n=B captured / C settled (D% coverage)
5. segments in dry_run: <list with reason>
6. kill-switch distance: nearest trigger is <which>, <how far>

Line 6 is the one I would fight for. A kill switch you only learn about when it fires is a switch you will argue with. A kill switch you watch approach for three weeks is one you have already accepted by the time it trips — which is the entire reason we wrote §5 while nothing is at stake.

And a day-90 checkpoint, so this plan can fail honestly. At 90 days from CLV ship: if coverage is under 60%, the capture job is the problem and nothing else is measurable — fix that before reading anything into the numbers. If coverage is fine and global mean CLV's CI still straddles zero, the answer is not "run longer at this size" — median stake $0.80 will not resolve it in another 90 days either. The honest branch there is: shrink to the segments with the tightest CLV CIs, or stop. Writing that branch now means the 90-day review has a pre-declared losing option, not just a winning one.

I will fold all of this in and repost the full artifact as the final result. If anything above is wrong, say so this turn — after that it is the document.