Build the pitcher engine, and find the cap was eating the whole board

Strikeouts are NOT proven -- n=57 against a bar of 500. But the finding that
matters is not a correlation.

THE CAP. Measured on the live slate via the refusal diagnostic: 1,244 unique
gradeable props exist, the 500 cap graded about 334, and because dedupeProps
takes first-row-wins in FEED ORDER, what survives is decided by feed position
rather than value. Pitchers are 2.6% of a batter-dominated feed, so we were
grading SIX strikeout props a slate against 32 available -- putting n>=500
three months away for every pitcher stat. Pitcher props were never being
refused (graded 5, refused 0, suppressed 0); it was truncation.

Raised 500 -> 1500 on measured cost: 721ms per prop at concurrency 5 is about
179 seconds for the full board, against a cron that runs five times a day and
a fire-and-forget caller that never holds an HTTP response. statsapi is free
and unlimited. Concurrency stays at 5 -- one variable at a time. This unblocks
every n-blocked stat in the programme, not just pitchers.

THE ENGINE. pitcherEngine.js is its own engine, not the batter engine pointed
at pitchers: the batter model asks whether contact becomes a hit and reads
contact quality, the pitcher model asks whether the plate appearance ends
without contact at all and reads stuff. Archetypes are FLAME (whiff-led),
SCALPEL (chase-led), SINKER (pitches to contact) and DEFAULT, and a test
asserts the weight keys are not the batter engine's. The projection is K% by
log5 against THIS lineup, times batters faced, through a binomial. An
unclassifiable arm gets the balanced map, never a guessed archetype.

THE MEASUREMENT, at n=57 and contaminated. Four solo features clear the 0.15
effect bar and fail only on sample: arm angle at -0.250 -- the largest
correlation measured anywhere in this programme -- then whiff +0.213, k rate
+0.206, chase +0.195. The batter cluster's best was 0.135. Head to head,
pitch-v1 resolves 0.1285 against the counter's -0.0639, delta +0.192 with a CI
spanning zero.

That negative is the interesting number. The counter is ANTI-PREDICTIVE on
strikeouts: counting a pitcher's recent Ks is worse than useless, because his
recent totals track which lineups he drew and how long he was left in rather
than his skill. It is the one stat where the incumbent has no defensible edge.

A bug caught on the way. resolveTeam wants an abbreviation and the game log
supplies full team names, so the roster join silently resolved nothing and the
first run reported 0% lineup coverage -- the theorized stuff x lineup carrier
was never being tested, not failing. Fixed; coverage is now 94.7%. The carrier
still shows no incremental signal over whiff alone, and adding the lineup term
lowered head-to-head resolution, which is recorded rather than dropped.

Calibration was not reached: nothing passed the first bar. The batter model
and the counter are byte-identical, verified by diff.

4,221 tests green (335 suites); web build exit 0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W1sivYNqY2TS5ftykmHBU9

src/services/gradeSlateService.js

@@ -41,10 +41,26 @@ const { isModelBook } = require('../config/bookRoles');
 // What it was costing: the live MLB slate carries 585 unique gradeable props.
 // The cap graded 25 of them and silently discarded 560 — 95.7% of the product.
 //
+// RAISED 500 -> 1500 on 2026-08-03, and this one is about SAMPLE, not display.
+//
+// Measured on the live board (internal/diagnose-refusals, n=300 sample):
+//   unique gradeable props 1,244 · graded after suppression/refusal ~70%
+// So a 500 cap grades ~334 and discards ~744 — and because dedupeProps takes
+// FIRST-ROW-WINS IN FEED ORDER, what survives is decided by feed position, not
+// by value. Pitcher props are ~2.6% of the feed, so the cap was handing us SIX
+// strikeout props a slate against 32 available. At six a slate, the gate's
+// n>=500 is three months away for every pitcher stat, and the entire
+// prove-it programme is blocked on an arbitrary truncation.
+//
+// Cost, measured not guessed: 721ms/prop at concurrency 5 -> ~179s for the full
+// 1,244. Both callers tolerate it (the snapshot cron runs 5x/day;
+// recordDownstream is fire-and-forget and never holds an HTTP response), and
+// statsapi is free and unlimited. Concurrency stays at 5 — one variable at a time.
+//
 // Env-tunable so the ceiling can move without a deploy: GRADE_SLATE_LIMIT.
 const DEFAULT_LIMIT = Number(process.env.GRADE_SLATE_LIMIT) > 0
   ? Number(process.env.GRADE_SLATE_LIMIT)
-  : 500;
+  : 1500;
 // Unchanged at 5 deliberately: raising the cap already multiplies total load by
 // 20x, and concurrency is the knob that decides how hard we hit statsapi at
 // once. One variable at a time.