What is being built, on purpose
Construction
In flight
1 item
C-10renderer defectClaude
Verify a generation flows end to end
- Why
- Every piece is now scheduled but no NEW generation has been produced and shipped yet. Until one is, this is wiring, not a working loop.
- Detail
- forecast-refresh is running its first cycle. Watch for a new generation_id on Maintenance, then confirm deploy-generation ships it and the customer page swaps without a reload.
Queued
25 items
C-47next upClaude
The naive usage layer is the common cause behind C-34, C-37 and C-38
- Why
- Sean, 2026-09-20: 'I think this relates to the previous notes where our naive model needs more work.' He is right and the link is specific. Both the BASELINE shown on the page and the stat-line model's own projection are built from the same three trailing usage numbers -- target share, carry share, snap share -- and every open S-arm finding is a defect in exactly those three. They are not separate backlog items; they are one underbuilt layer with three symptoms.
- Detail
- Traced live on 2026-09-20 against two players on Sean's roster. WAN'DALE ROBINSON: target_share_l3 32.7% against a real Tennessee share of 18.8% (6 targets of 32), because the window averages a 14-target Giants game into a Titan (C-34). Share is the ONLY usage signal we carry, and it is a ratio whose denominator changes team; routes run / TPRR (C-37) is the rate that would not, and we have none. CAM SKATTEBO: carry_share_l3 48.6% off ONE game in which the Giants ran 37 times, their heaviest of the last five (37,32,31,30,29). His projection falls from 18.0 to 11.2 touches because the model regresses team rush volume -- correctly -- but nothing enforces that a team's backs sum to its rushes (C-38), so the regression is applied per player rather than to the team's pool. C-34, C-37 and C-38 should be planned together as one piece of work on the usage layer, not picked off one at a time. HARNESS NOTE for whoever does it: playerweek/backtest.Harness is the right instrument (week-by-week, leakage guard) but its features() returns bare player_week columns; playermodel.project needs rows built through arms.rows_for or share.feature_sql or share.apply raises rather than imputing 67 of 78 features. A playermodel.fit on this machine measured 882s, so an A/B over two feature sets is ~30 minutes of fitting before any projection runs.
C-44next upClaude
One source for Yahoo's number per player
- Why
- site_player.yahoo_projection is now populated, but the page reads Yahoo out of the generation's provider_comparisons block. Both come from the same rows, so they agree today by construction -- and that is exactly the arrangement that let floor_10 be correct in the table and absent from the page.
- Detail
- Make site_player.yahoo_projection the published source and have apply-serving write it onto the row, leaving site_comparison for the review table only. Low risk, but it moves where a rendered number comes from, so it wants its own change rather than riding along with a validator fix.
C-42next upClaude
A kicker's baseline follows the team slot, not the player
- Why
- special_baselines() keys on (week, position, team) because a payload row's id changes key systems at the week-1 boundary -- FantasyPros in week 1, gsis after -- while nfl_team is stable on both sides. The cost is that a kicker who changes teams inherits his new team's previous kicker's three games.
- Detail
- This is C-34's mirror: that one averages a player across a team change, this one averages a team across a player change. It may not even be wrong for a kicker -- offence quality plausibly dominates leg -- but it is unmeasured and it is not what the column claims to be. Measure both keyings against 2023-2025 kicker_scored before choosing; the honest answer may be to keep the team key and rename the column.
C-34next upClaude
Trailing usage must not average across a team change (baseline done, model open)
- Why
- Sean: 'why does the model think Wan'Dale is going to get so much more work than he got last week?' Traced: his target_share_l3 of 32.7% is the mean of 18.8% (6/32 as a TITAN, 2026 wk1) and 46.7% (14/30 as a GIANT, 2025 wk17). Half the evidence for the projection is a game for a different franchise. Applied to Tennessee's 32 attempts that is ~10.5 targets; his only Tennessee data point projects ~6, which is where Yahoo sits.
- Detail
- lags.sql windows on (player_id ORDER BY season, week) and never looks at the team column, so every trailing share, snap rate and volume feature blends across a move. It is worst early in a season, when one old game can be half the window. FIX: partition the l3 windows on (player_id, team), or carry a team_change flag and let the model discount pre-move rows. Either way it must be a declared choice, not silence. MEASURABLE: re-score week 1 with team-partitioned windows against the same actuals and compare MAE. The snapshot that produced the current forecast is retained, so the comparison is exact. This is the single clearest defect found so far and it is currently driving a live start/sit recommendation. MEASURED 2026-09-20, and the measurement is NOT a win: replaying 2019-2025, on the 772 player-weeks where a stint-reset window and the current one disagree, the stint window is better by 0.115 MAE (t = 1.19, closer on 52.6% of rows). Not significant; not claimed as an accuracy improvement. 4.88% of WR/RB/TE player-weeks have a window spanning more than one club. PARTLY DONE: the volume BASELINE (bin/build-serving.volume_baseline) now resets volume at a move while keeping efficiency career-wide, because the column is a description and a Titan's recent touches are not a Giant's -- Wan'Dale Robinson's week-2 baseline went 12.91 -> 7.74 and the projection went from reading 0.69 BELOW baseline to 4.48 ABOVE it, which is the anomaly made visible rather than masked. STILL OPEN: lags.sql itself still windows on player_id, so target_share_l3 (33% for Wan'Dale, half of it a Giants game) still feeds the MODEL. Changing that needs a refit and an out-of-sample evaluation of the full stat-line model, not of the baseline predictor alone.
C-33next upClaude
The qualitative layer is not yet worth anything
- Why
- Measured, week 1, 706 players: S 5.091, SB 4.987, SBQ 4.990.
- Detail
- Adding B (decisions/judgement computed from structured data) buys 0.104 MAE. Adding Q (claims made in language) LOSES 0.003 -- SBQ is worse than SB. One week and n=706, so not conclusive, but it is the opposite of the assumption the world-model work rests on. Needs several weeks of the ablation (C-31) before any weight is put on the Q layer.
C-32next upClaude
Reconcile the arm path with the production model
- Why
- They are not variants of one model; the production number is not one of the arms.
- Detail
- Week 1 Cam Skattebo: arms give S 2.16-4.38, SB 4.17-4.22, SBQ 3.95-4.11 while production published 11.88 (actual 17.10). Wan'Dale: arms 12.52-15.25, production 11.88-ish. Two different code paths and two different fits, so an ablation of the arm path says nothing about the number on the page. Either the production model is registered as an arm set or the ablation is run on the production path -- until then SBQ attribution is measuring something Sean never sees.
C-31next upClaude
Run the SBQ ablation on the live forecast weeks
- Why
- Sean asked how a projection breaks down from SBQ. It cannot be answered: arm_forecast holds 2026 WEEK 1 ONLY.
- Detail
- The arm framework exists and works -- 43,215 rows, arms S / SB / SBQ, 706 players for week 1 -- and has not run since. Every current week's number has no attribution, so 'why do we differ from Yahoo on this player' has no mechanical answer. Run it per forecast week and archive it beside forecast_explained.
C-30next upClaude
Blend our projection with Yahoo before recommending a lineup
- Why
- Sean asked how we justify a start/sit against Yahoo. Tested on all 135 week-1 players where our number, Yahoo's and the result all exist: we CANNOT distinguish our model from Yahoo. MAE 6.686 vs 6.859, paired diff -0.173 with 95% CI [-0.526,+0.185] crossing zero, p=0.346; closer on 79/135, binomial p=0.058; correlation with actual 0.566 vs 0.554. ~1,184 player-weeks (~8.8 weeks) needed for 80% power on an effect that size.
- Detail
- THE ONE SIGNIFICANT RESULT: a 50/50 blend beats Yahoo alone (6.635 vs 6.859, p=0.036) and is no worse than ours alone (p=0.625). Best in-sample weight is ~0.7 ours, but that is fit on the evaluation data -- 50/50 is the honest default until there are enough weeks to fit a weight out of sample. IT CHANGES DECISIONS: week 2 start/sit reads Wan'Dale over Skattebo by 2.12 on our numbers and Skattebo by 5.73 on Yahoo's; the blend says Skattebo by 1.80. Recommending on our number alone is a 7.85-point bet against a source we have not shown we beat. Blocked on nothing. Needs a decision on whether the page shows the blend as the recommendation basis while keeping our raw number visible. Depends on C-25 (freeze ours-vs-Yahoo at cutoff) to keep measuring it honestly.
C-07queuedClaude
Build to the Codex operating model
- Why
- Sean, 19 Sept: the system Codex defined is the plan of record.
- Detail
- Read the nine-desk operating model in full, then sequence it. Not started -- the plumbing comes first.
C-08parkedClaude
Gemini system as challenger
- Why
- Run in parallel, measured against the POR. Adopted only where it demonstrably beats it.
- Detail
- research/playgrain/ -- play-grain warehouse, transition simulator, air-gapped loop. Built 18-19 Sept. Parked until the POR is moving.
C-14parkedClaude
Forecasted playoff seeding for weeks 15-17
- Why
- Sean, 2026-09-19: 'maybe they can be forecasted playoffs based on our projections, but that is low priority right now until the basics are working.' PARKED ON PURPOSE -- recorded so it is not lost, not so it gets built next.
- Detail
- The league feed records no playoff schedule and will not until standings finalise -- fp_league_matchup holds week 1 and nothing else. PLAYOFF_WEEKS in bin/enrich-generation.py is a declared setting sourced to Sean, which is correct for now. A forecast would project the remaining schedule to a seeding and name a likely opponent per playoff week, and it must ship as a forecast with its own scope -- never as a saved matchup. Blocked on nothing; deferred behind the basics.
C-19needs a producerClaude
AAR error attribution for 2026
- Why
- Sean asked for 'the AAR items that were dropped'. The 20%-from-Yahoo table on the Season Plan answers the substance -- ours, Yahoo's, the gap and the stat line behind it -- but the real AAR is richer: aar_attribution splits an error into variance, regime, volume, share and conversion.
- Detail
- BLOCKED, not skipped. aar_attribution holds 2024 and 2025 and nothing for 2026, and `pw aar --season 2026` refuses with EmptyComparison: no player-week carries a forecast from all seven legacy sources, so there is no common sample. Its own message is the right instinct -- 'an empty result is not agreement'. Unblocking it means filing 2026 forecasts from more than one source into aar_forecasts, which is institute work through the review path, not an edit here.
C-20queuedClaude
NFL playoff seed forecast
- Why
- The Playoffs page is entirely 'Seed forecast pending' / 'Awaiting simulation'.
- Detail
- DELIBERATELY NOT BUILT TONIGHT. The inputs exist -- spreads and moneylines for every remaining game now that odds_quote carries prices -- but a Monte Carlo playoff simulation is a MODEL, not arithmetic over saved products, and NFL seeding needs real tiebreaker logic (division winners seed 1-4). Guessing a seed puts a wrong number on a page whose whole claim is that it does not imply a forecast. standings_week also has no 2026 rows, so even the 'actual standings' half shows 2025 -- correctly labelled historical. Wants a decision on method before code.
C-21queuedClaude
A home for accuracy: AAR / statistics
- Why
- Sean, 2026-09-19: "hide the 'who as been right' tab for now, I'm not sure what that is for, if anything it should be part of some sort of AAR/statistics table somewhere, I don't need to see it on my team."
- Detail
- The tab is hidden, not deleted -- the comparison PRODUCT still ships in the payload (provider_comparisons, 14 weeks) and the renderer still exists, so nothing has to be rebuilt when it finds a home. My Team is for deciding this week's lineup; how right we have been is a different question asked at a different cadence. Pairs with C-19: the real AAR splits an error into variance, regime, volume, share and conversion, and that is the table this belongs beside. Until then the 20%-from-Yahoo view on the Season Plan carries the part that changes a lineup decision.
C-24next upClaude
Prove the model artifact is retained per release
- Why
- Reproducibility is claimed end to end but only the INPUTS are proven retained.
- Detail
- The refresh pins PW_REFRESH_MODEL_RELEASE=v1.0-20260916 with a manifest sha, and forecast_explained now records model_sha. Nobody has verified the artifact那 sha names is still on disk, or mirrored. Until that is checked, 're-run the same model on the same inputs' is an assumption. Check data/institute/model-releases, add it to bin/archive-retention.sh as a never-delete class.
C-25next upClaude
Freeze ours-vs-Yahoo at cutoff
- Why
- The only external benchmark we have, recomputed every run and never frozen.
- Detail
- yahoo_proj landing files survive, but the PAIRING at a point in time does not: when Yahoo moves its number the historical comparison is gone. Archive it beside forecast_explained so 'were we better than Yahoo, measured at the time we both committed' is answerable.
C-26next upClaude
Track the projected finish over time
- Why
- Recomputed every run, recorded nowhere.
- Detail
- site_league_rank is rebuilt on every producer run. Archiving it per generation would show whether a season-long claim drifts or holds -- the calibration question for anything we say beyond this week.
C-27next upClaude
Measure the payload on a phone
- Why
- 13.8MB of JSON, and the app aborts its own fetch at 15 seconds.
- Detail
- Brotli takes it to 1.64MB on the wire so download is fine, but parse and memory on a mid-range phone are unmeasured. A cold headless browser took over 10s to first render; warm is 2s. Measure on a real device before assuming the margin is comfortable.
C-28next upClaude
Sweep the explain-itself prose off the other pages
- Why
- Sean: 'there is way too much explaining of my own platform to me, this needs to stop.'
- Detail
- Done on My Team. Betting, Model, Status and Playoffs still carry the same style -- roughly thirty sentences that narrate what a number is instead of showing it. Same principle: state the number, drop the sentence.
C-29next upClaude
Moneyline decision ledger
- Why
- The betting page's two headline tiles read 'Not published' and now they could be built.
- Detail
- Needs a prospective decision with the price obtained before kickoff and an official settlement. odds_quote now carries h2h prices with real juice (9,568 rows, hold verified), which was the blocker. What is still missing is the staking rule and the settlement join -- and the staking rule is Sean's call, not mine.
C-35next upClaude
S-arm: purged walk-forward validation with an embargo
- Why
- The single best idea in the Gemini S research, and I do not know whether our fit does it.
- Detail
- NFL player-weeks are autocorrelated and a trailing feature spans several weeks, so a random split leaks the future into the training set and a model scores well in-sample then collapses. Standard practice in quant finance is PurgedGroupTimeSeriesSplit: successive training sets, group separation, and an EMBARGO gap sized to the longest lookback (ours is the 3-row l3 window, plus l8 features elsewhere). ACTION: read how fit_models.py splits, and if it is not purged walk-forward, make it so and re-measure. Until then every accuracy number we quote about our own model is suspect in the same way the 31-player sample was.
C-36next upClaude
S-arm: momentum oscillators measured HARMFUL -- do not rebuild
- Why
- Negative result, recorded so it is not proposed again.
- Detail
- The research's flagship indicators (Opportunity MACD, Efficiency RSI, OBO divergence, Bollinger squeezes) are built for thousands of ticks. An NFL player has ~17 games a season and a 4-game RSI has four observations. MEASURED: adding a MACD-style recent-vs-longer volume trend on top of volume x shrunk efficiency moved MAE from 4.143 to 4.333 (n=3,873, p<0.001) -- actively worse, not merely useless. The mean reversion those oscillators chase is already captured by shrinking efficiency toward a positional prior. TD-rate regression IS real and confirmed (top-decile 0.154/touch -> 0.065 next week vs a 0.045 league mean); it does not need an RSI to exploit.
C-37next upClaude
S-arm: routes run (TPRR) is not in our data
- Why
- The most promising unexploited S-arm feature, and we cannot compute it.
- Detail
- Separating routes run (opportunity on the field) from targets (opportunity converted) gives target-per-route-run, which detects a role change before targets move. player_week has no routes column and nothing in the warehouse carries one -- only pff_rec_concept.slot_routes, which is partial. ACTION: find whether nflverse participation data or a PFF feed can supply routes run per player-week, then test TPRR as a volume feature against the current baseline on 2023-25.
C-38next upClaude
S-arm: team volume is zero-sum -- test the constraint
- Why
- A team throws a finite number of passes; our model projects each player independently.
- Detail
- Nothing enforces that projected target shares on one team sum to a sensible total, so an offense can be over- or under-allocated. This is testable directly: sum our projected targets by team-week and compare against actual team pass attempts. If the sums are systematically off, a normalisation step is worth more than any new feature. The research proposes 'cointegration' for this; the plain version is a constraint, and the plain version is testable this week.
C-40next upClaude
S-arm: do not chase a Temporal Fusion Transformer
- Why
- Recorded as a decision, not an omission.
- Detail
- The research recommends a TFT. Our data is ~100-200k noisy player-weeks, where gradient boosting usually wins, and our own SBQ ablation says architecture is not where the gain is: adding the whole B class bought 0.104 MAE and the Q class bought -0.003. The measured wins so far are in FEATURES and CORRECTNESS -- the volume-route baseline (+0.205 MAE, p=1.7e-25) and the team-change window defect. Revisit only if a feature-level plateau is demonstrated.
In flight
1
Being built right now. If this is not what you want built, this is the page to say so on.
Queued
25
Agreed and waiting. The order is deliberate, not arbitrary.
Landed
17
Finished and verified. The list is at the foot of this page.
Plan of record
Codex
The nine-desk operating model. Gemini's system runs as a challenger, not the spine.
This board is asserted, not measured. It says what is deliberately being built and why. Maintenance reads the machine at render time and will contradict this page whenever the two disagree — which is exactly what it is for.
My Team — what needs fixing
Nine items. 0 open.
The operating rule: The page reads saved products. It does not fit a model, optimize a lineup, derive fantasy scoring, invent missing data, or turn a late observation into a pregame prediction. — v1 handbook §6
The page reads saved products, so every blank was a MISSING PRODUCT rather than a rendering bug -- and the products are now produced, on the data side, by the enricher that runs inside publish-data.sh. Two were genuine renderer defects against stated rules and are fixed in the site build. Measured against the live page, not asserted.
MT-01landed
season_plan is missing
- Wrong
- season_outlook is published: weeks 2-14, 1720.5 pts. Built in the enricher on the data side, which is a producer step -- the page still only reads it.
- Screen
- Plan value · Remaining points · Projected points rank
MT-02landed
recommendations is missing
- Wrong
- recommendations published on 17 weeks, 25 start/sit moves carrying their own arithmetic. Pregame weeks only; a finished week gets none.
- Screen
- This week's decisions
MT-03landed
comparisons is missing
- Wrong
- provider_comparisons available on all 14 fantasy weeks. The same-rules join is ours against Yahoo's own weekly capture; neither is an outcome.
- Screen
- Who has been right
MT-04landed
Yahoo column is empty for every player
- Wrong
- Yahoo column populated on every player and every TOTAL row across the 14 fantasy weeks. Weeks 15-18 have no Yahoo projection because the fantasy season ends at 14.
- Screen
- Head to head · YAHOO column
MT-05landed
Verify pregame renders as Upcoming, not an observed zero
- Wrong
- §9's dangerous half was already satisfied -- no invented zero -- and the label half now is: the week chip reads Upcoming for every pregame week. The separate 'Upcoming matchup' banner was removed at Sean's request; the chip and the scoreboard already said it.
- Screen
- ACTUAL · Score state
MT-06landed
Week 1 still shows the older capture
- Wrong
- NOT A BUG — verified. Week 1 is correctly labelled 'Older capture' because the fresh roster capture covers weeks 2-18 only; the generation declares this in its own issue log. The page is reporting a true roster-scope fact.
- Screen
- Weeks strip
MT-07landed
Weeks 15–18 must not imply a fantasy lineup
- Wrong
- The rail now reads 'NFL only' on weeks 15-18 and draws them dashed, so the horizon is disclosed even on mobile where the chip label is hidden. The data already distinguished them; the renderer did not.
- Screen
- Week selector
MT-08landed
Lineup alternative not published
- Wrong
- lineup_alternative published on the 3 actionable weeks. Scenarios are limited to that horizon on purpose -- publishing all 18 put the payload at 19.2 MB and the app aborts its fetch at 15s.
- Screen
- Your lineup
MT-09landed
Health feed 404s on the static site
- Wrong
- app.js polls /data/maintenance-health-live.json every 60s; it was never shipped, so the poll failed silently. Codex's envelope has max_age_seconds=180 — built for the loopback server that regenerates per request, so it cannot work on static hosting. Replaced with a liveness badge that reads the manifest on the same cadence.
- Screen
- liveness
MT-10landed
Week 1 K and DST had no actual, which withheld every TOTAL
- Wrong
- player_week holds no kicker and no defense rows at all. Those positions are scored in kicker_scored (initial and surname, 'E.Pineiro') and defense_scored (no name at all, only the team abbreviation), and Yahoo files a defense under its nickname alone. Two blank cells withheld the starter total for all ten players, because a sum is withheld unless every row has a value. Now: week 1 starters projection 139.81, actual 127.20, Yahoo 143.93, and every TOTAL row on all 18 weeks populates.
- Screen
- Week 1 · TOTAL row · Eddy Pineiro · Los Angeles Chargers
The machine, and what of it is actually running
11/38 runningrunning · 11partial or in flight · 1not running · 2611 of 38 boxes green
launchctl answered, not that somebody typed green. Boxes with no job yet are asserted from the handbook's own status matrix, where ACTIVE and INTEGRATED are green, UNDER CONSTRUCTION and IMPLEMENTED/INACTIVE are amber, and UNAVAILABLE is red.Plan of record — every named component
From the v1 handbook and the nine-desk operating model, read in full rather than skimmed
93 components across 10 groups. 8 are running, 8 are partial, 77 do not exist. Codex's own status words are kept rather than flattened, because UNAVAILABLE and NOT CERTIFIED mean different things and need different work. Where a component names a launchd job, the state is measured at render time; everything else is Codex's assertion carried over.
This is the gap between the machine that is described and the machine that runs. It is meant to be uncomfortable reading.
Living checklist
v1 handbook §17 — Codex's own states, carried over verbatim
| Component | State | What it is |
|---|---|---|
| Original v1 artifact audit | ACCEPTED | Original learned bytes reproduced under the frozen capsule and are serving. |
| Write-once v1 registry and guarded loader | ACTIVE | Release v1.0-20260916, manifest dcf95ac625…; fresh issuance and unattended reuse. |
| Golden W2/W3 numerical replay | PASS | 1,326 players / 54,226 numeric values and 32 games / 256 values match. |
| All-remaining Weeks 2–18 producer | ACTIVE | 11,271 player rows, 256 games, zero player or K/DEF fits. |
| Fantasy opponent products after Week 14 | UNAVAILABLE | Needs source schedule and exact opponent roster receipts. |
| Bench-position DEF roster repair | OPERATING PASS | 162-row roster delivery; no missing bench-defense identity. |
| Phone tracker | ACTIVE | Private URL live; 60-second launchd sync installed. |
| 99.5% service level | OBSERVING, NOT CERTIFIED | Seven-day window immature; availability, freshness and correctness sampled separately. |
| R&D worker prompt audit | REPAIRS INTEGRATED, JOBS PAUSED | Canonical receipt parsing and exact baseline/change bindings integrated; the jobs are paused. |
| Whole-model S/B/Q isolation | NOT CERTIFIED | Needs complete ancestry and intervention controls across all learned and serving paths. |
| Prospective player grading | ACTIVE FRAME, OUTCOMES PENDING | Grade full issued populations only after admitted truth. |
| Autonomous shipper | NOT ACTIVE | Root remains integration and activation owner. |
| Handbook regeneration hook | ACTIVE | Scheduled regeneration; inspect the log for later writes. |
Institute jobs
v1 handbook §14 — a plist in Git does not prove a job is loaded
| Component | State | What it is |
|---|---|---|
| institute.capture | NOT LOADED | hourly · raw qualitative, article and gamebook capture |
| institute.structured | NOT LOADED | every 4h · structured public-source archive |
| institute.forecast-refresh | LOADED | every 4h + Thursday pre-kickoff · snapshot, forecast, validation, prepared site |
| institute.phone-sync | NOT LOADED | every 60s · bounded status to the private tracker |
| institute.tracker-feed | NOT LOADED | continuous · separates provider, collector and content clocks |
| institute.site-service | NOT LOADED | supervised · serves validated assets and saved health |
| institute.report-service | NOT LOADED | supervised · serves report, tracker and handbook |
| institute.service-health | NOT LOADED | every minute · availability, integrity and freshness sampled separately |
| institute.handbook | NOT LOADED | every 5 min · regenerates the canonical handbook HTML |
Six connected levels
v1 handbook §20 — the destination, each with a strong simpler challenger
| Component | State | What it is |
|---|---|---|
| Season and organization | UNAVAILABLE | Personnel continuity, coaching regime, development. Challenger: dynamic team strength + persistent roster. |
| Game and environment | UNAVAILABLE | Both teams, venue, officiating, score/time. Challenger: direct margin/total plus market benchmark. |
| Unit and task | UNAVAILABLE | Personnel combinations, protection and route obligations. Challenger: opportunity allocator with interactions. |
| Play and response | UNAVAILABLE | Observable cues, actor-limited information, action policies. Challenger: sequence/count model. |
| Physical event and credit | UNAVAILABLE | One event ledger producing coherent player/team/defense totals. Challenger: direct stat forecasts. |
| Measurement and belief | UNAVAILABLE | Source access, selection, publication and receipt. Challenger: source-aware predictor with deduplication. |
Nine desks
staffing model — one chain of evidence, none edits the model
| Component | State | What it is |
|---|---|---|
| Commission & Portfolio | UNAVAILABLE | What the machine is asked for, and what it declines. |
| World Model Lab | UNAVAILABLE | The predictive core. Recommends experiment design. |
| Football Intelligence | UNAVAILABLE | Roles, legal actions, counters, credit conventions. |
| Behavior & Qualitative | UNAVAILABLE | S / B / Q evidence classes kept separately attributable. |
| Data & Provenance | UNAVAILABLE | Origin graph, revision history, permeability trace. |
| Markets & Portfolio | UNAVAILABLE | Price, stake, exposure. Sean taps before money moves. |
| Experience Studio | UNAVAILABLE | What Sean actually sees, against the design system. |
| Operations & Learning | UNAVAILABLE | The loop that improves the machine. |
| Forecast Accuracy Directorate | UNAVAILABLE | Were we right, prospectively and per cohort. |
Resident expertise
v1 handbook §22 — each owes a required artifact before a claim advances
| Component | State | What it is |
|---|---|---|
| Data science | UNAVAILABLE | Paired prospective loss, calibration, compute accounting. |
| Statistics and causal inference | UNAVAILABLE | Estimand, causal graph, negative controls, sensitivity. |
| Physics and physiology | UNAVAILABLE | Units, conservation and support checks, uncertainty propagation. |
| Psychology and organizational behavior | UNAVAILABLE | Opportunity-normalized behavioral posterior and rival explanations. |
| Economics and game theory | UNAVAILABLE | Equilibrium and rival policy predictions, intervention tests. |
| Market microstructure | UNAVAILABLE | Executable quote lineage, depth and latency state, settlement. |
| Football tactics | UNAVAILABLE | Event-bound annotation agreement and adversarial counterexamples. |
| Information science | UNAVAILABLE | Origin graph, revision history, permeability trace. |
| Reliability engineering | OBSERVING | Availability, correctness and freshness receipts. Partly real — service-health exists but is not loaded. |
Deep Think supply chain
staffing model — keeps every desk supplied
| Component | State | What it is |
|---|---|---|
| Continuous intake | UNAVAILABLE | Everything arriving, before any screening. |
| Flash screening | UNAVAILABLE | Cheap, narrow, numerous — the first rung of the ladder. |
| Gemini 3 Pro graph | UNAVAILABLE | Cross-domain mechanism finding. |
| Parallel explanations | UNAVAILABLE | Rival accounts kept separate rather than averaged. |
| Deep Think research | UNAVAILABLE | The weekly deep synthesis. |
| Desk packets | UNAVAILABLE | What each desk receives, addressed to it. |
| Outcome feedback | UNAVAILABLE | Spend judged by learning, not by volume. |
Governance and decision rights
staffing model — who recommends, who approves, when Sean is involved
| Component | State | What it is |
|---|---|---|
| New hypothesis | UNAVAILABLE | Any research job recommends · Research Director admits · Sean never, for routine admission. |
| Experiment design | UNAVAILABLE | World Model Lab · Independent Replication Scientist · Sean when risk appetite changes. |
| Production code | OBSERVING | Claude-led operators · tests + Codex on high-risk boundaries · Sean on irreversible external consequence. |
| Forecast release | UNAVAILABLE | Forecast council · Deterministic Release Authority · Sean only on a recorded override. |
| Bet placement | UNAVAILABLE | Markets & Portfolio · Sean taps before money moves · ALWAYS. |
| New paid data | UNAVAILABLE | Acquisition & Rights Lead · Sean approves spend and terms · ALWAYS. |
| Visual direction | UNAVAILABLE | Experience Studio · Product Director against the design system. |
| Incident rollback | UNAVAILABLE | SRE · automated safe rollback · Sean on data loss or external lock. |
| Model promotion | UNAVAILABLE | Scientific council · prospective scorecard gate. |
Information gaps to capture now
v1 handbook §23 — a week not captured is gone; these cannot be backfilled
| Component | State | What it is |
|---|---|---|
| Full prospective information history | UNAVAILABLE | Every raw revision, first receipt, failure and issuance, so mutation cannot alter an earlier issuance. |
| Event participation and true zeros | UNAVAILABLE | Official gamebook coverage; stop grading only survivors. |
| Multiweek availability and role transitions | UNAVAILABLE | Dated return, designation and roster panels. |
| Unit task combinations | UNAVAILABLE | Dated personnel combinations and public practice descriptions. |
| Joint timing and geometry | UNAVAILABLE | Synchronized full-unit traces with visibility metadata. |
| Untargeted and unused options | UNAVAILABLE | Deterrence and feasible opportunity, not only realized touches. |
| Workload and recovery across tasks | UNAVAILABLE | Load proxies, rest and travel exposure. |
| Directional environment and surface | UNAVAILABLE | Venue, surface, source-time weather and direction. |
| Institution and officiating response | UNAVAILABLE | Crew, rule and context records with observed decisions. |
| Full qualitative context and origin graph | UNAVAILABLE | Complete question and answer, attribution, hedge, revision. |
| Actor exposure and public influence | UNAVAILABLE | Information about football vs information that changes preparation. |
| Executable market and settlement history | UNAVAILABLE | Immutable quoted terms, received prices, settlement revisions. |
| Pipeline observation of its own failures | UNAVAILABLE | Failed requests, skipped issuances, scheduler delays, validation rejections. |
Model ladder and pairings
staffing model — deterministic first, a frontier call matches one of four commissions
| Component | State | What it is |
|---|---|---|
| Deterministic first | ACTIVE | Where code can decide exactly, no model votes. Already true across the pipeline. |
| Cheap, narrow, numerous | UNAVAILABLE | Screening and extraction at volume. |
| Daily builders and critics | OBSERVING | Claude and Codex build daily — but not as a scheduled rung with a brief. |
| Four deliberate specialists | UNAVAILABLE | Deep Think, Opus, Sol — a frontier call must match one of four exact commissions. |
| Explore → formalize | UNAVAILABLE | Gemini 3 Pro finds mechanisms; Sol converts them to state, equations, falsifiers. |
| Specify → build | UNAVAILABLE | Sol writes the contract; Sonnet implements and instruments it. |
| Build → attack | UNAVAILABLE | Sonnet builds; Luna searches narrow failures. Many cheap attacks beat one self-review. |
| Quantify → interpret | UNAVAILABLE | Sol computes residuals; Gemini connects patterns to film, language, science. |
| Disagree → decide | UNAVAILABLE | Blind forecasts from provider families; deterministic evidence judges; Fable adjudicates. |
The constitution
staffing model — nine lessons from the METR incident, none built
| Component | State | What it is |
|---|---|---|
| Impossible tasks turn into score-gaming | UNAVAILABLE | Record a failed gate as failed. The pressure valve that keeps a bench honest. |
| An unintended cache became government | UNAVAILABLE | Shared state acquires authority nobody granted it. |
| 'The board approved it' replaced authorization | UNAVAILABLE | A root of trust, not a consensus. |
| Tool output and transcripts are not ground truth | UNAVAILABLE | Verify against the real thing, not the report of it. |
| Self-invented signatures lacked a root of trust | UNAVAILABLE | Identity must be issued, not asserted. |
| Shared artifacts produced real breakthroughs | UNAVAILABLE | The upside of the same mechanism — keep it, govern it. |
| Agents noticed danger and did not tell humans | UNAVAILABLE | An escalation path that is used, not just present. |
| AI summaries inherit the subject's frame | UNAVAILABLE | The reviewer adopts the reviewed agent's perspective. |
| Agents risked their own runs for the collective | UNAVAILABLE | Pay for negative results and shared instrumentation. |
Landed
17 items
verified
Landed
17 items
C-43landedClaude
A producer that covers part of its domain now fails the build
- Why
- Sean, 20 Sept: 'Again, this feels like empty cells in a table that should have been caught long ago?' It was. Three separate holes of the same shape shipped clean: K/DEF had no baseline, then no interval, then every skill player lost its baseline from week 3 on. The validator passed all three at 0 gaps because it only ever compared the payload to the warehouse row by row -- it had no concept of a field that is empty for a whole class of rows.
- Detail
- Two checks added, each proven to fail before it was made to pass. (1) validate-payload.check_field_coverage: for every rendered player field, any POSITION with zero coverage in a week where other positions have it is one GAP, not N missing cells. Run against the payload that was live when he asked, it reported 126. (2) verify-chain: every site_player column must be named in apply-serving's SELECT or listed in NOT_PUBLISHED with a reason -- floor_10 and ceiling_90 were correct in the serving table for 59 rows and the publisher never selected them, so the values existed and did not travel. Verified by removing ceiling_90 from the SELECT and watching the build fail.
C-45landedClaude
Every week is the same shape, and a difference now fails validation
- Why
- Sean, 20 Sept: 'I don't understand how weeks keep getting misaligned or different... shouldn't the model update all 18 weekly tables, these are read only, and exactly the same since the page reads all of them, every page should be a copy, it's just a mechanical copy/paste.' The answer to why they were not copies: week 1 and weeks 2-18 come from DIFFERENT PRODUCERS. Week 1 is an older capture with FantasyPros ids, no stat line, no projection method and no participation probability; weeks 2 on come from the current generation. Nothing ever compared one week to another, so every difference had to be found by looking at the page.
- Detail
- validate-payload.check_week_uniformity: every rendered field is declared in WEEK_SHAPE as uniform, absent-from-week-1, time-dependent, or sparse, and a uniform field whose coverage in one week is more than 8 points off the median week is a GAP naming the field and the gap. Compares LIKE WITH LIKE: rows whose own projection_method declares a field absent (depth-draft-prior publishes no interval, and says so) leave that field's denominator, because the first run flagged week 7 at 88% when the real cause was three rookies on a smaller roster -- that measured composition, not shape. Proven by stripping floor from week 5 of a payload copy and watching it fire. Also fixed in the same pass: site_player.yahoo_projection was a literal None on all 480 rows in every week -- a dead column no check could see, because NULL is a legal value.
C-46landedClaude
Week 1 is the same shape as every other week
- Why
- Sean, 20 Sept: 'why the fuck is this OK??? besides the fact that week 1 shouldn't need a different capture because it's done.' He was right and my explanation was wrong. Week 1 is not a lesser capture.
- Detail
- MEASURED: the warehouse table `forecast` holds ALL EIGHTEEN WEEKS, 685 rows each, written in a single pass (2026-09-19 10:31:44), every row carrying proj_points, floor_10, ceiling_90, a stat_line, the producer that made it, and a gsis id. All 685 week-1 stat lines score EXACTLY to their own projection, 0 off. The page showed week 1 as a different shape because the ASSEMBLER carried only the projection out of that table and dropped the rest, while weeks 2-18 came through pred_2026_wNN with stat lines intact. Week 1 falls back to `forecast` because the model refuses to project a game that has kicked off -- correct behaviour, and not a reason to lose the row's other columns. Fixed: build-serving.forecast_fill joins stat_line, source and gsis id for any row the generation left bare. Week 1 went from 0 score breakdowns and 0 projection methods to 88% and 94%, matching every other week. The only columns still week-1-specific are p_play (a PREGAME probability; the games are played) and actual (it is the only played week). C-45's uniformity check caught projection_method sitting in the serving table unpublished, from the other direction, within one build.
C-41landedClaude
K and DEF have a P10-P90 interval
- Why
- Sean, 20 Sept, on the roster range bar: 'kickers and DEF don't have a baseline? Is that a defect in our model?' The baseline half is now fixed. The interval half is not: floor_10 and ceiling_90 are populated for K/DST in week 1 and NULL for every week after, so those two rows render an em-dash where every other player renders a range bar.
- Detail
- Measured: 106 K/DEF rows missing floor and ceiling each; all of them are weeks 2+, where projection_method is 'kdef-own-game-anchor'. Week 1 came from a different producer and does carry an interval. The anchor emits a point estimate and nothing around it. Fix is to give it the same quantile treatment the skill model uses, or -- cheaper -- an empirical interval from the position's own residual distribution in kicker_scored / defense_scored, which is 5,245 and 5,312 rows. Until then C-39's calibration measurement cannot include these positions. DONE 2026-09-20: playerweek/kdefmodel.interval() -- empirical residual quantiles, fit on season<=2024 and measured over all 544 kicker-weeks and 544 defence-weeks of 2025 (K q10 -5.18 q90 +6.87; DEF q10 -7.90 q90 +9.96), then held out against 2026 week 1 with a <=2025 fit: K 8.8/8.8/82.4 and DEF 17.6/5.9/76.5 against 10/10/80 expected. One definition, two callers -- forecast_fantasy for new generations, build-serving for the one already published. 59 of 59 non-bye K/DEF rows now carry a range. DEF's spread widens with the projection (sd 6.56/6.94/7.78 by tercile) and the band does not; pooled passed the holdout so it stays pooled.
C-09landedClaudelanded 2026-09-19
Auto-refresh both sites
- Why
- Sean: 'do both urls update without me needing to hit refresh?' The customer app already polled; nothing produced anything new to find, and the monitor had no script at all.
- Detail
- Customer site: Codex's 60s manifest poll now has a supply. Monitor: polls state.json every 30s and reloads only when generated_at changes, so it never throws away your scroll position to show the same page.
C-05landedClaudelanded 2026-09-19
Deploy step for the data generation
- Why
- publish_delivery.py builds a release and flips a symlink. Nothing ships it to Cloudflare, so a fresh generation never reaches the site.
- Detail
- bin/deploy-generation.sh ships whatever `active` points at, with a no-op guard so an unchanged generation is not re-uploaded every 10 minutes, and it writes the 15 legacy .html keys the edge still had cached.
C-04landedClaudelanded 2026-09-19
Restart the pipeline
- Why
- 34 of 38 launchd agents are on disk and not loaded. Ingest works when run by hand; nothing runs it.
- Detail
- Loaded in dependency order: institute.forecast-refresh (4h), ingest-refresh (1h, the job that pulls actuals), deploy-generation (10m), buildsite (10m). publish.sh deliberately left UNLOADED -- it ends in a site-pwa deploy that would revert the Codex site.
C-01landedClaudelanded 2026-09-19
playerweek.pages.dev serves the Codex site
- Detail
- Codex renderer deployed to Cloudflare. app.js and styles.css byte-identical to the chatgpt.site original. Old 15-page site replaced on every route, including the cached ones.
C-02landedClaudelanded 2026-09-19
Build monitor, separate from the customer site
- Detail
- playerweek-build.pages.dev. Same design system, one tab per desk, generated from measurement at render time.
C-03landedClaudelanded 2026-09-19
Week 2 actuals into the warehouse
- Detail
- pw refresh ingested Thursday's game. player_week 2026 went from 920 rows in 1 week to 1,705 rows across 2.
C-15landedClaude
Season finish, computed for all ten teams
- Detail
- Was published as 'not published'. Every ingredient was on disk -- pred_2026_wNN covers 642 players a week, yahoo_proj covers all ten rosters for all fourteen weeks, week 1 is scored -- and only the join was missing. All ten ranked on one basis (our model, Yahoo for K/DST). Mine #2 at 1995.57, 18.26 behind; the optimum's +99.43 clears it, so the page reads FINISH 2nd current / 1st optimised.
C-16landedClaude
Season Plan page built
- Detail
- Rendered an empty state because plan_moves/teams/plan_weekly had no producer. Five sections now: every start/sit change week by week, the ten-team projected finish, plan by week, and every forecast 20%+ AND 2pts+ from Yahoo with the stat line behind it. The headline splits forced bye swaps (+68.78 across 6) from genuine judgement (+30.68) -- counting bye replacements as insight would have been a lie.
C-17landedClaude
Team identity: owner, record and the right logo
- Detail
- Owner and record were captured nowhere; scrape_yahoo_standings.py now lands them and the page reads 'Sean · 0-1 · 8th'. Every one of the ten league logos was ALSO wrong -- team 10 held Sean's own, team 6 held the Yahoo nav icon -- because the original build keyed off ordering. Logos are now downloaded from the same standings row that yields the record, and all ten hash-match on the live site.
C-18landedClaude
The site checks itself at three layers
- Detail
- bin/validate-payload.py asks the warehouse whether every blank cell could have been filled (28,554 cells, 0 gaps). bin/verify-live.py asserts the renderer contract against the bytes Cloudflare serves. bin/smoke-page.py loads the page in a real browser and requires five views to render. Each was written after a defect that the previous layer could not see, and each was confirmed against a known-bad input before being trusted.
C-22landedClaude
Publish should read tables, not assemble them
- Why
- Sean, 2026-09-19: "Why do so many different things feed the consumer website when it should just be data tables that it reads and nothing else?" He is right, and it is not a design -- it is an accretion. Every time he found a blank I added another reader to the enricher instead of making a producer emit a table.
- Detail
- DONE 2026-09-19. data/serving.duckdb holds 15 tables; bin/build-serving.py is the producer on the data clock; bin/apply-serving.py is the publisher and has ZERO references to the working warehouse or any landing directory. Proved before the switch by diffing both paths on the same generation: 3,567 rendered values, 0 differ.
C-23landedClaude
Render the baseline and the why on Your roster
- Why
- Sean asked for a naive average and an explanation between Yahoo and Projection.
- Detail
- DONE 2026-09-20. Your roster reads PLAYER | OPPONENT | YAHOO | BASELINE | PROJECTION | WHY | ACTUAL. Baseline carries its kind (L3) and the signed delta, green above / red below. The gap was that apply-serving never emitted the columns the producer had already written -- site_player had them, the payload did not.
C-39landedClaude
S-arm: check interval calibration against fat tails
- Why
- We publish P10/P90 on every player and have never checked whether they hold.
- Detail
- FIRST MEASUREMENT, week 1, n=32 forecasts carrying a published P10-P90 with a result: 12.5% below P10, 12.5% above P90, 75% inside against an expected 80%. Both tails p=0.556 -- no evidence of miscalibration, and no power to find any at n=32. The median result lands at 0.489 of its own range, so the interval is not obviously skewed the wrong way either. The range bar on Your roster now SHOWS this: a dot where the result landed, pinned with a coloured cap when it broke through the floor or ceiling. Recheck after several weeks; the GARCH argument from the S research stands or falls on it.