report: C1 takeable-floor derivation — CANNOT DERIVE (every bucket CI spans zero)
MLB decided overs n=296, 100% with locked_odds. ROI by locked-price bucket shows every 95% CI containing zero; the curve is NON-MONOTONE and runs opposite to the premise (deepest buckets positive, the -111..-160 middle most negative); and price bucket is confounded with market (+200up = doubles/HR longshots). Rows needed per bucket to resolve a 5-pt edge: 661-2285 vs actual 8-71 (~187 days for one bucket at current accrual). The inherited -160 is neither confirmed nor refuted. The no-ceiling call is not supported by this data either (+200up is the worst bucket) though it is not refuted - it stays a design choice, not a data-backed one. Recommends C2 proceed with -160 as an explicitly-labelled POLICY floor plus a re-derivation trigger (any negative bucket n>=300, or end of MLB regular season; adopt a derived floor only when a bucket CI excludes zero). Enumerates all 9 takeable sites, incl. the live drift hazard (backend env-tunable, frontend hardcoded) and the user-visible band copy in PriceTriplet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QJs13VsyiSKYQP6rj3NNmc
This commit is contained in:
@@ -331,6 +331,74 @@
|
||||
> **HELD:** edge_pct rescale/retirement (Order B) · board columns/contract unchanged · tier-keyed proxy
|
||||
> caching. Dashboard visual is auth-gated → TAGGED FOR THE CHROME AUDIT, not faked.
|
||||
|
||||
> ## 🔬 C1 — TAKEABLE FLOOR DERIVATION 2026-07-30 (report-only): **CANNOT DERIVE — the data does not support ANY floor number**
|
||||
> Read-only. Nothing tagged, built, or changed. **The SHAPE (floor on minus, uncapped plus) is Kev's
|
||||
> ratified call and is not in question — this order could not supply the NUMBER, and says so rather
|
||||
> than dressing a guess as a derivation.**
|
||||
> **0.1/0.2 POPULATION — VERIFIED.** MLB decided (hit/miss) **OVERS = 296**, Jul 11-30, and **100%
|
||||
> carry `locked_odds`** (0 missing — the floor is about the price you could actually bet). **METHOD
|
||||
> NOTE:** derived over ALL prices, NOT pre-filtered to the current −160..+200 band — pre-filtering
|
||||
> would be CIRCULAR and would empty the very deep buckets the floor must judge.
|
||||
> **PHASE 1 — ROI BY LOCKED PRICE (flat 1u, 95% CI on the mean return):**
|
||||
> | bucket | n | hit% | breakeven% | **ROI%** | 95% CI |
|
||||
> |---|---|---|---|---|---|
|
||||
> | +200 and up | 39 | 20.5 | 22.0 | **−13.15** | [−68.6, +42.3] |
|
||||
> | +100..+199 | 51 | 52.9 | 44.5 | **+19.31** | [−12.0, +50.7] |
|
||||
> | −110..+99 | 8 | 62.5 | 51.3 | +21.60 | [−48.2, +91.4] **TOO THIN** |
|
||||
> | −111..−135 | 32 | 50.0 | 55.8 | **−10.55** | [−42.1, +21.0] |
|
||||
> | −136..−160 | 43 | 53.5 | 60.1 | **−11.68** | [−36.6, +13.2] |
|
||||
> | −161..−200 | 71 | 69.0 | 64.6 | **+6.46** | [−10.3, +23.2] |
|
||||
> | worse than −200 | 52 | 73.1 | 69.7 | **+4.75** | [−12.7, +22.2] |
|
||||
> **🔴 THREE FINDINGS THAT BLOCK A DERIVED FLOOR:**
|
||||
> **(1) EVERY 95% CI CONTAINS ZERO.** Not one bucket is statistically distinguishable from zero ROI.
|
||||
> Phase 2 asked for "the deepest price where ROI is still positive WITH MARGIN" — **no such bucket
|
||||
> exists.** Any floor drawn here is drawn through noise, which this order explicitly forbids.
|
||||
> **(2) THE CURVE IS NON-MONOTONE AND RUNS OPPOSITE TO THE PREMISE'S MODEL.** The premise reasons that
|
||||
> deep-negative prices are structurally −EV ("the price ate the edge"). The data shows the **deepest
|
||||
> buckets are the POSITIVE ones** (−161..−200 → +6.5%; worse-than−200 → +4.8%, hitting 73.1% against a
|
||||
> 69.7% breakeven) while the **most negative ROI sits INSIDE the current takeable band** (−111..−160 →
|
||||
> ≈ −11 to −13%). Read literally this data says "avoid −111..−160," which is almost certainly noise —
|
||||
> and that is exactly why it must not be turned into a floor.
|
||||
> **(3) A REAL CONFOUND: price bucket is entangled with MARKET.** +200-and-up is `doubles/home_runs`
|
||||
> (rare-event longshots, avg line 0.53); the deep-negative buckets are `hits/total_bases` ("will he get
|
||||
> a hit"). Holding the market constant (hits + total_bases only) the non-monotone shape PERSISTS
|
||||
> (+100up +22.6 · −111..−135 **−13.4** · −136..−160 **−13.5** · −161..−200 +6.5 · worse-than−200 +4.8),
|
||||
> so the confound is not the whole story — but it means a price-only floor would partly be encoding
|
||||
> "avoid HR/doubles props," which is a market rule, not a price rule.
|
||||
> **POWER — how far the data runs out.** Rows needed PER BUCKET to resolve a 5-point ROI edge at 95%:
|
||||
> **661-2,285.** Actual bucket sizes: **8-71.** We are 10x-100x short. At the observed accrual (18.5
|
||||
> decided MLB overs/day; 4.44/day into the −161..−200 bucket) reaching 828 rows in that ONE bucket
|
||||
> takes **~187 days** — and the MLB season ends well before that, so it will not accrue continuously.
|
||||
> **THE INHERITED −160 IS ALSO UNVALIDATED (neither confirmed nor refuted).** In-band (−160..+200) ROI
|
||||
> **+3.84%** [−13.0, +20.7] vs out-of-band **−0.04%** [−16.1, +16.0] — a ~3.9-point gap with massively
|
||||
> overlapping intervals. Post-fix-only (≥2026-07-19, the model-version cutoff): in-band +7.91%
|
||||
> [−11.7, +27.5] (n=102) vs out-of-band −2.07% (n=112). Directionally friendly to the current band,
|
||||
> statistically silent.
|
||||
> **PHASE 2.6 — THE NO-CEILING CALL IS NOT SUPPORTED BY THIS DATA EITHER (stated straight).** The
|
||||
> +200-and-up bucket is the WORST performer (ROI −13.15%, hitting 20.5% against a 22.0% breakeven).
|
||||
> It is confounded (doubles/HR) and n=39 with a [−68.6, +42.3] interval, so it does not REFUTE the
|
||||
> no-cap call — but it certainly does not support it. **Uncapped plus-money remains a defensible
|
||||
> design/risk choice; it should not be described as data-backed.**
|
||||
> **RECOMMENDATION FOR C2 (so it is not blocked on a number that cannot be derived):** ship the floor
|
||||
> as an explicitly-labelled **POLICY** floor — keep **−160** (inherited, already the band everywhere,
|
||||
> and directionally the better half of the only comparison available) — and **label it in code and copy
|
||||
> as a policy choice pending derivation, NOT as derived**. **RE-DERIVATION TRIGGER (so "provisional"
|
||||
> cannot silently become permanent): re-run this order when ANY negative bucket reaches n ≥ 300, or at
|
||||
> the end of the MLB regular season, whichever comes first — and only adopt a data-derived floor when a
|
||||
> bucket's 95% CI EXCLUDES zero.**
|
||||
> **0.3 — EVERY `takeable` DEFINITION SITE C2 MUST UNIFY (9):** **DEFINITIONS (2):**
|
||||
> `src/config/valueEngine.js:21-22,30-35` (env-tunable `TAKEABLE_ODDS_CEILING`/`TAKEABLE_ODDS_MAX`,
|
||||
> defaults −160/200) · `web/src/lib/valueState.js:42-43,72-77` (**HARDCODED −160/200**).
|
||||
> **🔴 LIVE DRIFT HAZARD FOR C2:** the backend is env-tunable and the frontend is hardcoded, so
|
||||
> changing `TAKEABLE_ODDS_CEILING` in prod TODAY would silently desync the two. **CONSUMERS (7):**
|
||||
> `src/utils/gradeRanking.js:25,56` (hero + server board) · `src/services/heroPropService.js` (via
|
||||
> gradeRanking) · **`src/services/intelligence/analyzeViaEngine1.js:567`** (stamps `legacy.takeable`
|
||||
> onto every graded prop — this is the one that reaches the snapshot/ledger) ·
|
||||
> `src/config/valueEngine.js:40` (`isValue`) · `web/src/lib/slateAdapter.js:474,478` (client board) ·
|
||||
> `web/src/lib/valueState.js:82` (`isValue` mirror) · **`web/src/components/vyndr/PriceTriplet.tsx:9-10,68`
|
||||
> (renders the band IN USER-VISIBLE COPY — "Takeable band −160 to +200", so a floor change is a copy
|
||||
> change too).**
|
||||
|
||||
- **Redirect EXISTS + WIRED:** `closingCapture.buildCaptureRows`→`closing_captures` (append-only,
|
||||
provenance: captured_at/book/line_type/both-prices/missed_reason) via `intradayRefreshService:221`
|
||||
+ internal endpoint; `ledgerService.attachClosingProb`→`closing_prob` (de-vigs both raw sides,
|
||||
|
||||
Reference in New Issue
Block a user