builtbykev/vyndr
1
0
Fork 0
Code Issues Pull Requests Actions 6 Packages Projects Releases Wiki Activity

docs: edge-shading challenger measured — flooding persists, input scale is the bug

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QJs13VsyiSKYQP6rj3NNmc
This commit is contained in:
Kev
2026-07-31 00:39:51 -04:00
parent c2c7abbb65
commit 1e9c808d99
2 changed files with 71 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
outputs/VYNDR-COMPLETION-MATRIX.md
+26
View File
@@ -516,3 +516,29 @@ below floor), 8 NULL with `null_despite_price = 0`; settled 1,163 and graded 1,2
stamping one would record a model transition that never happened.
312 suites / 3,890 tests green, web build exit 0.
---
# EDGE-SHADING CHALLENGER — built + measured 2026-07-31 → `specs/edge-shading-challenger.md`
Challenger only; champion byte-identical; nothing promoted. The mechanic is sound and built
(`adjusted = raw_edge × f(e)`, `f` bounded to (0,1], one fixed bar that never moves; same raw 6% edge
→ **A** in soft `mlb:total_bases`, **B** in sharp `nba:points`, unit-proven).
**But the measurement says the flooding is NOT fixed:** on 1,250 live rows the challenger grades
**79.0% A / 80.9% A-or-B** (MLB 93.4% A) vs champion 0.2% A.
**Why — two findings.** (1) **The shading is a no-op on the live board: 0 of 1,250 rows are actually
shaded.** 96.5% are unscored (f=1) and the one scored market present is the anchor (f=1.0 by
construction); `mlb:strikeouts` and `nba:points` are absent from the ledger entirely (our basketball is
`wnba`). (2) **The input scale is the bug, not the placement.** Against a fixed 5% bar the RAW edge
already clears A on 100% of MLB doubles and 89.6% of hits, with MLB's median raw edge at 60% — twelve
times the bar. **Applying the sharpest score in the spec (f=0.647) to every row still leaves 75.8%
clearing A.** A multiplier bounded ≤1 cannot close a 12× overshoot.
`edge_pct` is a price-free `(proj−line)/line` gap whose scale is a function of line size — not a
betting edge, so no fixed betting-edge bar is meaningful against it. **Unblocking needs the input
replaced (`p_win` vs `fair_prob`, both already stored), not the multiply moved**, plus scores fit from
our own record for the 9 of 11 live markets that have none.
313 suites / 3,899 tests green, web build exit 0.
specs/STATE.md
+45
View File
@@ -617,6 +617,51 @@
> **FLOOR: 312 suites / 3,890 tests green (8 new), web build exit 0.** Grade visuals auth-gated →
> Chrome audit; this order changed nothing visual.
> ## 🧪 EDGE-SHADING CHALLENGER BUILT + MEASURED 2026-07-31 → `specs/edge-shading-challenger.md`
> **Verdict: the mechanic is sound and built — but it does NOT fix the flooding, and the measurement
> proves the bug was never the multiply's placement.** Champion byte-identical (diff empty across
> `intelligence/`, `gradeSlateService`, `gradeAdapter`, `snapshotService`, `grade_thresholds.json`).
> Nothing promoted, nothing re-lettered.
> **0.1 THIRD RE-CHECK: the flat additive ±0.05 efficiency nudge STILL DOES NOT EXIST** — no
> `efficiency` reference anywhere in `src/services/intelligence/` or `gradeAdapter`. There was nothing
> to remove. **0.2 no live base threshold exists**, so the challenger DEFINES one that never moves
> (A+≥10, A≥5, B≥3, C≥1, D≥0, F<0), identical for every market — the spec's per-sport 5%/7% variant is
> deliberately unused because a bar differing by sport IS a moving bar.
> **BUILT** (`src/services/challengers/efficiencyShading.js`, measured-never-served, fence-tested):
> `adjusted = raw_edge × f(e)`, `f(e) = E_SOFTEST/e` **bounded to (0,1]** — soft intact (never
> amplified), sharp shaded toward but not past zero (`f(.60)=.917`, `f(.80)=.688`, `f(.85)=.647`),
> unscored → `f=1` FLAGGED, absent edge → null. **Cross-market behaviour is unit-proven: the same raw
> 6% edge grades A in soft `mlb:total_bases` and B in sharp `nba:points`.**
> **🔴 PHASE 2.5 ANSWER: THE FLOODING IS NOT GONE.** On 1,250 live rows the challenger grades **79.0%
> A / 80.9% A-or-B** (MLB **93.4% A**) against the champion's 0.2% A / 58.1% A-B. The naive formula's
> 86% A/B is not meaningfully improved on.
> **TWO FINDINGS EXPLAIN IT — and they are the point of the order. (1) THE SHADING IS A NO-OP ON THE
> LIVE BOARD: `rows_actually_shaded = 0` of 1,250.** 96.5% (1,206) of rows are **UNSCORED** → `f=1`,
> and the one scored market present (`mlb:total_bases`) is the ANCHOR so its `f` is 1.0 by
> construction. `mlb:strikeouts` and `nba:points` **do not appear in the ledger at all** — our
> basketball is **wnba**, not `nba`. **Challenger vs baseline: 0 rows changed.**
> **(2) PLACEMENT WAS NEVER THE BUG — THE INPUT SCALE IS.** Against a fixed 5% bar the **RAW** edge
> already clears A on **100% of MLB doubles, 100% stolen_bases, 89.6% hits, 88.6% total_bases —
> before any shading**. MLB's median raw edge is **60%, twelve times the bar**. **DECISIVE TEST: apply
> the SHARPEST score in the whole spec (f=0.647) to EVERY row — the maximum the design permits — and
> 75.8% STILL clear A (MLB 91.7%).** Since `f` is bounded ≤1, **no achievable shading can close a 12×
> overshoot**; moving the multiply from threshold to edge cannot change that. This is `edge_pct`
> behaving exactly as the 07-29 diagnosis described — a price-free `(proj−line)/line` gap whose scale
> is a FUNCTION OF LINE SIZE. **It is not a betting edge, so no fixed betting-edge bar is meaningful
> against it.**
> **2.6 efficient-market over-suppression: CANNOT DETERMINE** — zero live rows are shaded, so there is
> no efficient market in the data to over-suppress.
> **PHASE 3:** takeable tagging was completed in the PREVIOUS order (migration 034, 1,246/1,254 rows,
> floor −160 recorded per row) — **not repeated, it would be a no-op**. The model-version boundary is
> **again NOT applied**: nothing promoted, so no boundary exists; stamping one would record a
> transition that never happened.
> **UNBLOCKING NEEDS THE INPUT REPLACED, NOT THE MULTIPLY MOVED:** a bar-based grade needs a real edge
> — model probability vs the de-vigged market price (**`p_win` vs `fair_prob`, both already computed
> and stored**) — plus scores **FIT from our own record** for the markets we actually grade (9 of 11
> live markets have none; inventing them would be fabricated calibration). The mechanic itself is
> sound and already built, so that re-run is cheap.
> **FLOOR: 313 suites / 3,899 tests green (9 new), web build exit 0.**
- **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,