# SPEC — LEDGER TAKEABLE TAGGING (built) + MULTIPLICATIVE EFFICIENCY SCALING (BLOCKED)
2026-07-31. Champion grade UNCHANGED. Push scoring untouched.

---

## PART A — THE EFFICIENCY CHALLENGER: **BLOCKED, NOT BUILT**

### Review Zero came back ABSENT on all three inputs

- **0.1 efficiency scores — DO NOT EXIST.** Zero occurrences of `market_efficiency`,
  `marketEfficiency`, or `efficiency_score` in `src/` or `web/src/`. `src/config/` holds
  no efficiency file (the one `0.80` there is `providers.js WARN_PCT`, a quota warning).
- **0.2 base thresholds — DO NOT EXIST.** There is no "MLB A: 5% edge / NBA A: 7% edge"
  table. `engine1.js` contains **zero `edge` references**; the grade is not an
  edge-vs-threshold comparison. `grade_thresholds.json` holds PROBABILITY bands.
- **0.3 the ±0.05 additive nudge — DOES NOT EXIST.** Searched the whole grade path. The
  only `0.05` values are `featureCache.teammate_absence_bump` (a feature), a
  `bvp_advantage` cutoff for a matchup letter, and `p*0.9 + 0.05` inside
  `probabilityEstimator` (the `0.5 × 0.1` term of the shrink-toward-0.5, not efficiency).
  **There is no additive efficiency application to replace.** No market-conditional logic
  exists in `engine1.js` or `analyzeViaEngine1.js` at all.

### Why the challenger cannot be built as specified

The order requires a challenger differing from the champion in **EXACTLY ONE thing —
multiplicative vs additive scaling**. That construction is impossible here:

- there is no additive scaling to swap,
- there is no base threshold to multiply,
- and `engine1.js` has **zero `sport` references**, so market/sport cannot reach the grade.

To have a threshold to scale, the challenger must FIRST grade on probability-vs-threshold —
which is rule **R1 of `specs/full-output-grade-mapping.md`**, an explicitly held separate
order. Shipping R1+R4 together would (a) violate the isolate-one-variable requirement and
(b) make the Phase-3 delta report **misleading**: the re-letter would be driven mostly by
switching to probability grading, presented as the efficiency fix. Kev would be approving
the wrong attribution. **That is why this half stopped rather than guessed.**

### 0.4 — coverage gap that would sink the build anyway

The spec names 5 scores (NFL passing .85, NBA points .80, MLB K .60, MLB TB .55, NBA role
.55). The live public ledger contains **11 markets**: MLB hits (376 rows), doubles (247),
total_bases (44), stolen_bases (17), earned_runs (6), home_runs (4), outs (2); WNBA points
(246), rebounds (156), assists (142), threes (10). **Only MLB total_bases maps to a specced
score.** MLB K's and NFL passing do not appear at all; WNBA is not in the spec list. So
**9 of 11 live markets have NO score** — and the guardrail ("all scored markets, or it's
incoherent") cannot be satisfied without inventing 9 numbers. Inventing them would be
fabricated calibration.

**What Part A needs before it can run:** (1) R1 probability grading, so a threshold exists;
(2) efficiency scores for the markets we actually grade — ideally **FIT from each sport's
own accrued record**, not hand-set (that is R4's stated design).

---

## PART B — LEDGER TAKEABLE TAGGING: **BUILT** (the deferred C2)

Independent of Part A: it needs no threshold, no scaling, no grade change.

### The standard (`src/config/takeableStandard.js`)

    isLedgerTakeable(american) = american >= LEDGER_TAKEABLE_FLOOR   // default -160
    // FLOOR on the minus side, UNCAPPED on the plus side.

**🔴 It is deliberately NOT `valueEngine.isTakeable`.** Those answer different questions:

| | shape | question |
|---|---|---|
| `valueEngine.isTakeable` | −160..+200, **bounded both ends** | "may we PROMOTE this to the hero / top of board?" |
| `takeableStandard.isLedgerTakeable` | ≥ −160, **uncapped plus** | "was this a price a bettor could actually have TAKEN?" |

A **+400** prop is **NOT promotable but IS takeable** — both true at once. A unit test asserts
they diverge on the plus side and agree at the minus floor, so the two can never quietly merge.

**Absent price → `null`, never `false`.** Without the strict guard `Number(null) === 0` is
≥ −160 and a MISSING price would be tagged takeable — fabricated data in the record.

**The floor is POLICY, not derived, and is labelled so everywhere.** C1 (2026-07-30) could not
derive one: every price bucket's 95% ROI interval contained zero, the curve was non-monotone
(deepest buckets positive), and resolving a 5-point edge needs 661–2,285 rows/bucket against
actual sizes of 8–71. −160 is held because it is directionally the better half of the only
available comparison (in-band ROI +3.84% vs out-of-band −0.04%, both spanning zero).
**Re-derivation trigger:** any negative bucket reaching n ≥ 300, or the end of the MLB regular
season — and adopt a derived floor only when a bucket's 95% CI excludes zero.

### Schema (migration 034, applied + tracked)
`ledger_entries.takeable boolean` + `takeable_floor numeric`, both nullable, plus a partial
index on `(sport, takeable) WHERE user_id IS NULL`. **`takeable_floor` records the floor each
row was judged under**, so a future re-derivation can re-tag safely instead of guessing which
standard a row was tagged by. Additive only — nothing deleted, nothing re-settled.

### Forward + backfill
Forward: `ledgerService` stamps `takeable`/`takeable_floor` at row build from the locked odds.
Backfill: every row with a parseable locked price, one statement, no outcome/grade/price touched.

**Result — 1,254 rows: 1,246 tagged (781 takeable / 465 below floor), 8 NULL, and
`null_despite_price = 0`** — i.e. every priced row is tagged and the 8 NULLs are genuinely
priceless rows (honest absence). One distinct floor (−160). Settled 1,163 and graded 1,254
both unchanged.

---

## PART C — MODEL-VERSION BOUNDARY TAG: **DELIBERATELY NOT APPLIED**

Phase 2.4 asks for a boundary separating pre-fix (additive) from post-fix (multiplicative)
grades. **No scaling change shipped, so no such boundary exists.** Stamping one would mark a
model transition that never happened — a fabricated era in the permanent record, which is the
exact class of thing the Data Semantics Rule forbids. `src/config/modelEras.js` (Session 64)
is the correct home for it **on the day a real scaling change promotes**.

---

## VERIFY
Champion grade path untouched (`engine1`, `analyzeViaEngine1`, `probabilityEstimator`,
`gradeSlateService`, `grade_thresholds.json` — no diff). **312 suites / 3,890 tests green**
(8 new), **web build exit 0**. Grade visuals are auth-gated → Chrome audit; this order changed
nothing visual.

## TAGS
VERIFIED: efficiency scores/base thresholds/±0.05 nudge all absent; 11-market coverage gap;
tagging built + backfilled + integrity-checked. CANNOT DETERMINE: none. **BLOCKED: Part A
(the efficiency challenger) — needs R1 probability grading plus fitted per-market scores.**