mlb_conditions_anchor

1. 🔴 The fatigue number is mostly a calendar lookup — and the setting we ship passes four games in five

Two problems that compound. First the measurement. A team's two-day reliever pitch count has no denominator: a club that played Monday and Tuesday is being compared with a club that had Monday off. Across the 1,288 team-games where we hold both prior slates, teams that played both days average 126.5 pitches and teams that played one average 69.3 — a ratio of 1.83, very close to the 2:1 in games. Knowing nothing but the schedule predicts whether a team clears the default 90 correctly 81.0% of the time (81.4% of the played-both group clear it, 20.3% of the played-one group).

Then the threshold. The shipped recipe "Gassed bullpen" — "trade games where a bullpen has thrown a lot of pitches over the last 2 days" — is {metric: bullpen, side: either, above: 90}, and it is also the builder's field default and the docstring's own example. "either" takes the larger of the two teams' totals, which is a maximum of two draws from a distribution whose mean is 111. The result: 555 of 701 stored games pass — 79.2%, and 132 of the 160 open MLB game markets today.

The fair counter-case, which is stronger than it first looks. For a gate, calendar load genuinely is the first-order fatigue signal. The dominant reason a bullpen threw 126 pitches instead of 69 is that it worked two nights instead of one, and that is not a confound so much as the mechanism doing its job. The metric is not wrong about baseball. Two things follow anyway, and they are what makes this a catch rather than an observation:

• The expensive part earns almost nothing. Walking thirty boxscores four times a day to recover a number that is 81% predictable from one bit — did they play twice — is a lot of machinery for a schedule lookup. Whatever edge exists must live in the other 19%, and nothing in the config isolates it.
• The interesting case is exactly the one it cannot express. Ninety pitches from a single fourteen-inning night is a different animal from forty-five and forty-five, and a bettor cares about the difference. Both produce the same number here, and there is no field that separates them.

The dial itself is not broken; it is pointed at the wrong end of its own range. both rather than either at the same 90 cuts to 47.2%, at 120 to 19.7%, at 160 to 2.9%. So this is a bad default on a real metric, not a useless metric — and the way to read the 79.2% is "this recipe is on by default", not "bullpen fatigue is junk".

2. 🔴 A fully rested bullpen is stored as “no data”, so the gate cannot see it

_bullpen_fatigue() builds a dictionary of team → pitches from the games that finished in the window. A team that did not play appears in no game, so it is absent from the dictionary, so fatigue.get(team_id) returns None and NULL goes into the row. The gate then fails closed. Zero pitches and no information are written as the same thing.

That matters most in the direction the signal is quietest about. above is the "gassed pen, buy the over" thesis. below is the opposite one — a fresh pen, so the late innings are safe — and the freshest possible bullpen is precisely the one the gate cannot admit, because two days off is indistinguishable from a dead feed.

The cleanest demonstration is 17 July 2026, the first full slate after the All-Star break. MLB played 15 games that day; we stored 14 (the fifteenth, Pittsburgh at Cleveland, was postponed and turned up as one half of a doubleheader the next day). The trailing window was 15 and 16 July, which between them held one game in the whole of Major League Baseball — Mets at Phillies — and neither of those clubs was on the 17 July slate. So all 28 bullpen values across all 14 games were NULL, and the gate was shut on every game on the board, in both directions, on the one day of the season when "every bullpen in baseball is rested" was unarguably true.

The distinction worth holding on to: failing closed on an outage is right. This is failing closed on a defined zero — a value the world actually produced and the poller declined to write. The defect is upstream, in writing NULL where it could write 0 for a team it can see on the schedule and can see did not play.

3. 🔴 More than a quarter of these games are played indoors

park_temp and park_wind are the outdoor conditions at the stadium's coordinates. Checked against MLB's own fieldInfo.roofType for every venue in our table: of the 701 stored games, 509 were in open air, 166 at parks with a retractable roof, and 26 at Tropicana Field, which has a fixed dome. That is 27.4% where the number we store may describe the sky above a closed roof, and 3.7% where it certainly does.

Tonight makes the point without any need for statistics. We have 98.7 °F stored for the Rockies at the Diamondbacks. Chase Field has a retractable roof; Phoenix in August does not play with it open. A {metric: park_temp, above: 95} gate — "heat helps the ball carry" — will admit that game on a reading taken outside an air-conditioned building. Rogers Centre and loanDepot park are on tonight's slate too, at 71.5 °F / 15.7 mph and 86.6 °F / 14.1 mph respectively.

Be precise about what is and is not fixable here, because they are two different things. Roof type is free and we ignore it: MLB returns fieldInfo.roofType on the very endpoint the poller already calls — it asks for hydrate=venue(location) and could ask for the field info in the same request. Storing that alone would let a bot exclude the eight parks where the question is meaningless. Roof state — open or shut for this particular game — is the thing you actually want, and we do not ingest it from anywhere. This page is not going to guess at it, so every retractable game in the table stays in the "unknown" column above rather than being quietly assigned to one side.

4. 🔴 The copy promises direction; the code measures magnitude

Worth separating the two claims, because only one of them is broken. The code's thesis is defensible: a windy park is a windier park, and gust speed is a crude but genuine proxy for conditions that move fly balls, pop-ups and command in either direction. The copy's thesis is not measurable at all. The docstring says a gust matters because "wind blowing out inflates scoring / home runs"; the builder's novice explanation says "wind blowing hard at the park pushes more balls out". Both describe direction, and the gate reads a scalar. A 20 mph wind blowing straight in from centre field — which suppresses scoring — is indistinguishable here from 20 mph blowing straight out.

Open-Meteo returns wind_direction_10m on the identical call, free. Verified while writing this: the same request that gave us Busch Stadium's gust today also carries 256°, a wind from the west-south-west. We do not ask for it.

Being fair about the size of the fix, because it is bigger than one parameter: direction alone would not finish the job. Turning "from 256°" into "blowing out" needs each ballpark's home-plate-to-centre-field bearing, and we hold that nowhere — not in the poller, not in the schedule payload, not in any table. So this is a two-part change: fetch a field we are already entitled to, and build a thirty-row table of park orientations. Neither is hard. Neither exists.

Related, and not merely cosmetic: metric: "park_wind" returns the gust. Sustained wind is fetched, stored in park_wind_mph on all 701 rows, selected by the gate's own SQL, and then never read by anything. The docstring is honest about this; the field name is not, and the gap between the two numbers is large enough to matter. Gust runs a mean 4.3 mph above sustained (median 3.5, max 18.9), so a user who sets park_wind above 15 picturing a steady fifteen-mile-an-hour breeze gets a gate that opens on 28.4% of games instead of the 3.7% sustained wind would have given them — nearly eight times as often as intended, silently.

5. 🟠 Forty-eight hours with no data at all — caused by our own backtest index

The poller has run 226 times. 217 wrote rows. Nine died on sqlite3.OperationalError: database is locked at the INSERT OR REPLACE, and all nine are consecutive: every scheduled run from 00:41 on 10 August to 00:41 on 12 August. Nothing was written for two whole days. game_date = '2026-08-10' and '2026-08-11' hold zero rows, so for forty-eight hours the gate returned false for every MLB market on either book.

The cause is bracketed cleanly at both ends. predictive/ticker_index.py — the index that made backtests 47× faster — was replaced at 22:18 UTC on 9 August. The poller's next scheduled run, 00:41 on the 10th, was the first failure, and it never recovered while that version was live. A fix named lockfix landed at 02:47 UTC on 12 August. The poller's very next run, 06:41, succeeded, and every run since has. Nine failures inside the window; zero in the 217 runs outside it.

The mechanism is a scheduling collision that is not bad luck but arithmetic: ticker_index refreshes on cron minutes 1, 11, 21, 31, 41 and 51, and this poller's slot is minute 41. Every single run of this poller starts in the same second as an index refresh. That was survivable for eight weeks. It stopped being survivable when the refresh started running 99–124 seconds while holding the write lock, against this poller's SQLite busy timeout of 20.0 seconds. The fix moved the scan out from under the lock: post-fix the log reports the write lock held 0.12 to 22.06 seconds (mean 3.35) inside a run that still takes about 129 seconds.

Two honest qualifications. The pre-fix log recorded only a total elapsed_s, not a lock duration — the write_lock_s field is the fix — so the evidence for the mechanism is the bracket and the collision, not a measured pre-fix lock time. And 1 of the 89 runs since the fix still held the lock for 22.06 s, which is longer than this poller's timeout. The risk is much reduced; it is not gone.

This also settles a question left open on the injury_anchor page, which wondered whether a poller's start-minute offset predicts whether it survives. It does not. lineup_poller at :27 has never failed; this one at :41 collides on every run and also never failed, for eight weeks. What decides it is how long the lock is held versus the client's busy timeout — a duration, not an offset.

6. 🟠 The gate's clock is UTC. Baseball's day is not.

The lookup is datetime.now(timezone.utc).strftime("%Y-%m-%d") against a game_date that MLB assigns on local time. Those two agree through the afternoon and part company for the best part of the evening. The clean, assumption-free number: 176 of 701 games — 25.1%, the west-coast nights — have not thrown a first pitch until the UTC date has already rolled over. The wider figure is 65.2% still in progress after UTC midnight, though that one rests on an assumed 3 h 05 m game, so treat it as an estimate and the 25.1% as the fact.

What the gate does in that window is the part that deserves the emphasis, and it is not "fails closed". The poller writes the new UTC date's slate at 00:41, so from 00:41 UTC (8:41 pm Eastern) the table has rows for the date the gate is asking about — they are just tomorrow's games. The gate does not fail. It answers confidently about a different game, at a different park, with a different bullpen. And because this table is never pruned, tonight's rows are still sitting right there, one date value away: the data is not missing, the query is looking past it. In the 41 minutes before the poll it is worse only in the sense of being honest — no rows for the new date, so nothing trades.

This is the same disease as lineup_anchor catch #3, and the two pollers differ in a way that matters: lineup_poller fetches two dates a run, today and tomorrow, so at least its roll-over lands on rows it deliberately prefetched. This one fetches today only. And on 10 and 11 August the two faults stacked — the clock had rolled onto a date the poller had also failed to write, so the gate was not looking at the wrong slate, it was looking at nothing at all.

7. 🟠 “side: home” does not mean the team you asked about

That a per-game condition returns one answer per game is half a tautology, so take it as read: "Will the Phillies win?" and "Will the Cardinals win?" get the identical verdict, always. The footgun is the field that looks like it fixes that and does not. side reads as "the team in the title"; it means the home or away team of that game. Tonight, a bot asking about the Phillies with side: "home" is handed St. Louis's bullpen total of 132, not Philadelphia's 104 — verified by calling the gate directly on both titles with all three settings. There is no value of any field that says "the team I am betting on".

For a total that is fine — a total is a property of the game, and the module's three worked examples are all totals. The problem is the copy. to_novice_english tells the user a gassed pen is "useful for OVER / fade-the-favorite plays", and fade-the-favorite is a side thesis this gate has no way to express. Cross-referenced on the lineup_anchor page, where the same shape costs the shipped recipe half its trades.

8. 🟠 A weather market, judged on another city's weather

The title scanner is imported from lineup_anchor, so it inherits that module's city aliases, so it inherits the collision documented there and on injury_anchor. Of 10,242 open Kalshi markets right now, 196 titles match an MLB team and 36 are not baseball — 18 KXHIGHMIA and 18 KXHIGHPHIL, high-temperature markets for Miami and Philadelphia.

On the other two sports signals that is merely wrong. Here it is wrong in a way worth photographing. Verified live, by calling the gate directly: "Will the high temp in Philadelphia be >91° on Aug 12?" passes {metric: park_temp, above: 95} — because the Phillies are away tonight, at Busch Stadium, where the forecast reads 97.7 °F. A weather signal answering a weather question with the wrong city's weather. Philadelphia's own forecast is never consulted.

Under today's shipped default the same collision admits all 18 Philadelphia markets and none of the 18 Miami ones — not because anything protects Miami, but because the Marlins' game happens to read 40 pitches and fails the threshold. Those 36 are the complete list, not a sample: every one of the 10,242 open markets was scanned. The collision is bounded by an accident of the calendar — it can only fire in a city that is both a team alias and a city Kalshi runs a weather market in, which today is Miami and Philadelphia and nowhere else. Chicago, New York, Los Angeles and Denver are all team aliases and all currently safe, because no matching weather market is open. That bound is luck, not design.

It is latent rather than live: the engine applies its category filter in SQL before this gate ever runs, and all 76 strategies declare a category, so nothing routes weather markets here today. The gate offers no protection of its own; the surrounding query does. A ticker-prefix check would end it in one line — the same one-liner lineup_anchor needs, in a second module, for the third time.

9. 🟡 Doubleheaders: whichever row the database hands back first

The lookup ends in LIMIT 1 with no ORDER BY. When a team plays twice on a date — 22 team-days in our record — which row you get is undefined. Not random: SQLite will hand back whatever the scan reaches first, stably, which is the worst kind of undefined because it looks reliable. On 22 July the Orioles and Red Sox played a doubleheader and the query returns the 23:10 UTC game at 75.2 °F rather than the 17:35 UTC one at 81.2 °F. For the Pirates and Yankees the same day it returns the earlier game. Same query, opposite choices.

The bullpen figures are identical for both halves, so this only bites the two weather metrics — but six degrees is the difference between passing and failing a sensible threshold. And underneath the matching bug is a missing product decision that nobody has made: when a team plays twice, which game is the market about? Nothing in the config can express an answer, and nothing anywhere records which one you were given.

10. 🟡 The backtester skips it — and here the standing reason does not apply

mlb_conditions_anchor appears nowhere in quants/backtest.py — not in the supported set, not even in the documentary _UNSUPPORTED_ENTRY list. It is caught only by the catch-all that flags any entry key the replayer does not know. So a backtest that includes this rule runs without it, returns a curve for a different strategy, and flags unsupported_rules — a lie by omission rather than a lie, but the curve still looks like an answer.

The reason given in that file for the whole family of sports anchors is "only current state stored". For lineup_anchor and injury_anchor that is true, because their INSERT OR REPLACE is keyed on a pitcher or a player and overwrites history in place. Here it is keyed on game_pk, and a game happens once. Nothing is overwritten across days and there is no prune, so the table already holds 53 game-dates of real per-game history — and our Kalshi price tape covers 22 June onward, giving 48 overlapping dates and 1,370 MLB tickers with price snapshots. Both halves of a replay are sitting on the disk.

Be careful about how much that proves. It kills "only current state stored" as a reason this gate cannot be replayed; it does not by itself make a replay sound, and there are three real obstacles left. Only the last value written on a game's date survives, so what we hold is an end-of-day snapshot rather than an as-of-decision-time series. 152 of the 701 games start before the 18:41 write, so for those the stored weather was recorded after first pitch — an archive, but not a lookahead-free one. And of 1,896 MLB market rows only 130 currently carry a settlement result, so the settled sample is far smaller than 796,000 price snapshots makes it sound. The honest summary is that this is the only one of the four sports signals where the missing piece is work rather than data.

11. 🟡 Configurations that validate and cannot work

validate_config requires at least one bound, which stops the empty config. It does nothing about the values. {above: 0} validates and opens on every game with a number in it — so unlike lineup_anchor, which cannot be built into a constant, this one can. {above: 200, below: 10} validates and renders, in the builder's own English, as "either team's bullpen has thrown ≥ 200 pitches over the last 2 days and ≤ 10 pitches over the last 2 days". {metric: park_temp, above: 500} validates. This is the same unsatisfiable-range hole documented on finance_anchor and btc_dominance_anchor; no warning is issued anywhere.

In the same family, and gentler: the docstring's third worked example is "buy total UNDER only when the ballpark temp is < 50 °F", and no game in our record has ever been below 58.7 °F. That is not really the example's fault — our table starts on 17 June and baseball in June, July and August is warm. It is worth stating only because the table is never pruned, so the example that is dead today will come alive on its own next April. This is one of the few signals here where "wait" is a real answer.

12. 🟡 On an opener day, the first reliever is counted as the starter

"Relievers are every pitcher after the starter" is implemented as pitchers[1:], on the correct observation that the boxscore array is in order of appearance. That is right for a conventional start and wrong for an opener, where the man in slot 0 is a reliever and his pitches are silently excluded from the bullpen total.

This was an assumption on this page until we measured it. Across the 90 team-games on 7–9 August, 8 — one in eleven, 8.9% — had a slot-0 pitcher who threw fewer than 40 pitches: Erik Miller 17, Casey Legumina 13, JT Brubaker 16, Noah Schultz 23, Davis Martin 23, Daniel Lynch IV 35, Joey Cantillo 31, Chase Petty 38. Every one of those is bullpen work that the fatigue number does not see. The error is one-sided and modest — a 13-to-38-pitch undercount on roughly 9% of team-games — but it lands exactly where the metric is already weakest, and it will grow if openers do.