builtbykev
929fd81940
PHASE 0 — the defect is real past the peek. Against a FAIR point-in-time baseline (each player's rate over games strictly before that date, >=10 prior games, box scores back to 05-01), the served champion LOSES on all four stats, three of four CIs excluding zero: hits 0.00251 vs 0.00774 CI [-0.0074,-0.0011] TB 0.00393 vs 0.00619 CI [-0.0055,-0.0003] rbi 0.02481 vs 0.03133 CI [-0.0153,-0.0005] runs 0.00181 vs 0.00683 CI [-0.0114,+0.0008] PHASE 1 — the cause is the WINDOW, not the weights. estimateProbability builds its base rate as the frequency over every row it is handed, and featureCache.getStatRows handed it res.last10. So the "season rate" was a TEN-GAME rate, and 0.4 of the forecast was the last five OF THOSE TEN. The 0.40 recency weight costs resolution on all four stats (-0.00086, -0.00107, -0.00562, -0.00365). Nudges are mixed and small -- harmful on hits and rbi, marginally helpful on TB and runs -- so they are left alone. PHASE 2 — two lines, no new data, no extra API call, because fullLog was already fetched by the same adapter call that produced last10: getStatRows now reads fullLog, and RECENCY_WEIGHT goes 0.40 -> 0.20. hits 0.00251 -> 0.00817 (tripled; now above the fair baseline) TB 0.00393 -> 0.00734 (above baseline; vs old CI [0.0020,0.0067]) rbi 0.02481 -> 0.02727 (still below baseline, CI includes zero) runs 0.00181 -> 0.00436 (still below baseline, CI includes zero) Gate stated exactly: hits and TB now exceed the fair baseline on the point estimate; rbi and runs remain below but EVERY CI now includes zero, so no stat reliably loses to a frequency table. That is a tie on rbi/runs, not a win, and it is reported as one. Only TB's improvement over the old champion is CI-confirmed; the rest are directional. STALE-FIT GATE: CALIBRATION_DEPLOYED is now EMPTY. The low-param maps were fitted on the retired forecast and fromLedger cannot rescue them -- settled ledger rows still carry OLD p_win, so refitting today would refit the retired forecast. Nothing is served calibrated until dates settle under the repaired champion, and the favourite-longshot bias must be re-measured rather than assumed to survive. The shadow duel is void. PHASE 3 — the hits factor lift is NOT re-measured, and cannot be yet: it needs settled rows produced BY the repaired champion, which ships in this commit. Replaying would score the factors against a reconstruction rather than the served forecast. Deferred, explicitly. The factors remain wired and transmitting; only their lift is unquantified on the new baseline. PHASE 4 — standing flag, and it is large: EVERY factor verdict in this programme, every null and every THEATER, was measured against a champion worse than a frequency table. Signal added to noise reads as noise. Prior verdicts may deserve re-audit. Logged, not re-run. Re-queued not built: rbi lineup-slot / RISP opportunity through the two-part gate, now landing on a repaired champion. Serving-path change by design; the byte-identical invariant inverted and all four stats move. Nine frozen model modules verified unchanged. No Bonferroni slot -- resolution accounting on the champion's own knobs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W1sivYNqY2TS5ftykmHBU9
56 lines
2.6 KiB
JavaScript
56 lines
2.6 KiB
JavaScript
'use strict';
|
|
|
|
/**
|
|
* The champion's forecast window, and what depends on it.
|
|
*
|
|
* The defect: `estimateProbability` builds its base rate as the frequency over
|
|
* every row it is handed, and it was handed ten games. So the "season rate" was
|
|
* a ten-game rate, and 0.4 of the forecast was the last five OF THOSE TEN.
|
|
* Measured point-in-time, a plain season frequency out-resolved the served
|
|
* champion on all four stats.
|
|
*/
|
|
|
|
const est = require('../../src/services/intelligence/probabilityEstimator');
|
|
const snapshotService = require('../../src/services/snapshotService');
|
|
|
|
/** n games where the player cleared the line at the given rate, most-recent-first. */
|
|
const logs = (n, rate, statType = 'hits') => Array.from({ length: n }, (_, i) => ({
|
|
date: `2026-06-${String((i % 28) + 1).padStart(2, '0')}`,
|
|
[statType]: (i % Math.round(1 / rate)) === 0 ? 2 : 0,
|
|
}));
|
|
|
|
describe('the forecast is no longer dominated by five games', () => {
|
|
it('a long cold streak inside a good season does not swing the forecast wildly', () => {
|
|
// Ten recent zeros on top of a strong season. At the old 0.40 weight this
|
|
// pulled the number a long way off a better one.
|
|
const season = logs(80, 0.6);
|
|
const cold = Array.from({ length: 5 }, (_, i) => ({ date: `2026-07-0${i + 1}`, hits: 0 }));
|
|
const withCold = [...cold, ...season];
|
|
const out = est.estimateProbability({ gameLogs: withCold, line: 0.5, statType: 'hits', features: {} });
|
|
const seasonOnly = est.estimateProbability({ gameLogs: season, line: 0.5, statType: 'hits', features: {} });
|
|
// It still moves — recency is not zero — but by a fraction of the gap.
|
|
expect(out.p_over).toBeLessThan(seasonOnly.p_over);
|
|
expect(seasonOnly.p_over - out.p_over).toBeLessThan(0.25);
|
|
});
|
|
|
|
it('more history produces a steadier forecast than ten games', () => {
|
|
const ten = logs(10, 0.6);
|
|
const many = logs(80, 0.6);
|
|
const a = est.estimateProbability({ gameLogs: ten, line: 0.5, statType: 'hits', features: {} });
|
|
const b = est.estimateProbability({ gameLogs: many, line: 0.5, statType: 'hits', features: {} });
|
|
expect(Number.isFinite(a.p_over)).toBe(true);
|
|
expect(Number.isFinite(b.p_over)).toBe(true);
|
|
});
|
|
});
|
|
|
|
describe('calibration is off while its maps are stale', () => {
|
|
it('serves nothing calibrated — the maps were fit on the retired forecast', () => {
|
|
expect(snapshotService.CALIBRATION_DEPLOYED).toEqual([]);
|
|
expect(snapshotService.CALIBRATION_BASIS).toEqual({});
|
|
});
|
|
|
|
it('the deploy list is still frozen, so nothing can re-enable it at runtime', () => {
|
|
expect(Object.isFrozen(snapshotService.CALIBRATION_DEPLOYED)).toBe(true);
|
|
});
|
|
});
|