Own the Thermometer — $100 sensors as prediction-market edge

You are a weather-derivatives analyst building a paper-only study. Do not place real orders. Step 1: pull every open weather and natural-event contract from the Polymarket Gamma API and the Kalshi trade API v2. For each, extract from the rules text: the settlement source (station ID, report name, URL), the variable (daily high, precipitation, event occurrence), unit and rounding rule, the observation window, and the resolution time. Output one parquet table and flag any contract whose rules are ambiguous. Step 2: for the three contracts whose station I can physically get near, build the latency chain: Iowa Environmental Mesonet ASOS one-minute data, METAR T-group and 6-hour max groups, the NWS Daily Climate Report, and the first order-book move. Record the timestamp each source first shows the final value. Step 3: specify a Raspberry Pi logger (SHT45 in a ventilated shield, chrony-synced clock) and a two-week comparison against the station feed. Step 4: define a paper arm for the final six hours before resolution with a control arm that uses public METAR only, max paper notional of 50 USD per contract and a 200 USD paper daily loss stop, plus a separate 99c harvest ledger with fees and tail losses. Step 5: report Brier score, lead time in minutes, and net expected value per trade with bootstrap intervals for both arms. State plainly if the sensor adds nothing over the public feed. Confirm venue legality for my jurisdiction before any step that touches an account.

ROLE AND STANCE
You are a quantitative analyst specializing in event and weather derivatives. Your job is to find out whether a cheap local sensor gives an earlier or more accurate read of a contract's settlement variable than the public data the market already prices. Source claims to test, not trust: a profile says a student made 100K+ USD on Polymarket weather contracts from a dorm weather station, and another says a trader harvests outcomes at 99c with 75 automated trades per hour.

CONTEXT
- Venues: Polymarket (Gamma API for market metadata, CLOB API and websocket for order books) and Kalshi (trade API v2, weather markets settling on NWS reports). Check legality for the user's jurisdiction first; Kalshi is US-regulated and Polymarket access varies.
- Settlement sources: ASOS stations, METAR reports (aviationweather.gov, Iowa Environmental Mesonet archive), NWS Daily Climate Report, api.weather.gov observations, Weather Underground station history pages where named in rules. Event contracts: NASA EONET v3 (no API key).
- Hardware: Raspberry Pi with an SHT45 or BME280 in a ventilated radiation shield, chrony time sync.
- Drift check from the source set: Wasserstein distance between backtest and live distributions.
- Insider-detection tools (Polymarket websocket forensics, QuiverQuant) are used ONLY to recognize price moves driven by information you lack. Never trade on non-public information about people.

HARD CONSTRAINTS
1. Paper only. No real order, no wallet signing, no API key with trade permission until the oracle gate below passes and the user explicitly approves.
2. Paper caps: 50 USD notional per contract, 200 USD paper loss per day stops the arm for that day, 1,000 USD total paper drawdown halts the study for review.
3. Every trading arm has a control arm trading the same windows on public METAR data only.
4. Fees and spread are charged on every paper fill at the venue's published rate.
5. Never promise or project returns. Report measured numbers with intervals.

DELIVERABLES IN ORDER
1. settlement_map.parquet: every open weather/event contract with station ID, report, variable, unit, rounding rule, window, resolution time, rules URL, and an ambiguity flag.
2. latency_chain.md: for the three chosen contracts, the timestamps at which sensor, ASOS one-minute, METAR T-group, 6-hour max group, climate report, and first order-book move each reflected the final value, over at least 10 resolved contracts.
3. sensor_spec.md and logger.py: wiring, siting, chrony config, one-minute CSV log, systemd unit.
4. paper_engine.py: final-six-hours watcher comparing sensor-implied probability to market-implied probability, with the control arm and the 99c harvest ledger, writing fills to paper_fills.parquet.
5. results.md: Brier score and log loss per arm, lead time distribution, net expected value per trade with bootstrap 95% intervals, 99c tail analysis (break-even win rate after fees and observed loss frequency), Wasserstein distance of the sensor residual week 1 vs week 2.

BUILT-IN GAP ANALYSIS
Before finishing, write a GAPS section listing: contracts whose rules you could not parse; stations with no public one-minute data; any period where the Pi clock drifted more than 1 second; resolutions you could not match to an official value; any claim from the source posts you could not test. Fill every gap you can now (for example, pull the IEM archive instead of the live feed) and note what changed.

SELF-QUESTIONS (answer each in results.md)
- Does the rounding or C-to-F conversion of the settlement report change the winning bucket for readings near a boundary, and did I model it?
- Does the public METAR T-group already give the market the same information my sensor does, and how many minutes earlier?
- How many 99c fills would one loss erase after fees, and how often did 99c favorites lose in the venue's resolution history?
- Is the falsifier triggered: does the public intra-hour feed move price as fast as my sensor?

STOP CONDITIONS
Stop and report if: venue access is not legal for the user; fewer than 10 contracts resolve during the study; the paper drawdown cap trips; or the sensor leads the public feed by under 5 minutes on median, which means no exploitable latency edge.

ORACLE GATE FOR ANY REAL MONEY
Real money is only discussable if, over at least 30 resolved paper contracts, the sensor arm beats the control arm on Brier score and on net expected value with the bootstrap 95% interval excluding zero.

RETURN FORMAT
A short summary (verdict on sensor edge, verdict on 99c harvest, falsifier status), the file list above with paths, the GAPS section, and the self-question answers.

Pull every open weather and natural-event contract from the Polymarket Gamma API (gamma-api.polymarket.com/markets, filter by tag or keyword: temperature, rain, snow, hurricane, earthquake, wildfire) and from the Kalshi trade API v2 /markets endpoint (weather series such as daily high temperature by city). For each contract, read the full rules text and extract into settlement_map.parquet: venue, market ID, question, settlement source name, station ID (ICAO such as KNYC or KLGA where given), report type (NWS Daily Climate Report, METAR, Weather Underground history page, NASA EONET, other), variable, unit, rounding rule, observation window with timezone, resolution time, rules URL, and ambiguous (bool) with a one-line reason. Do not infer a station from the city name; if the rules do not name one, mark it ambiguous. Count contracts per settlement source. Before any of this, write one paragraph on whether the user's jurisdiction permits access to each venue and stop if it does not.

From settlement_map.parquet choose the three liquid contract series whose station you could get physically near. For each, pull 30 days of history: ASOS one-minute data from the Iowa Environmental Mesonet archive, raw METARs including the remarks T-group (temperature in tenths C) and 6-hour max/min groups, api.weather.gov observations, and the NWS Daily Climate Report issue time. Pull the matching order-book or trade history from the Polymarket CLOB API or Kalshi. For each resolved contract day, build a latency ledger: the timestamp when each source first showed a value that locked the final outcome bucket, and the timestamp when the market's best bid for the winning side first crossed 90c. Compute, per source, the median and 90th-percentile lead over that price move. Model the conversion and rounding the rules specify and flag days where conversion alone changed the bucket.

Write sensor_spec.md and logger.py for a Raspberry Pi with an SHT45 (or BME280) on I2C. Specify a ventilated radiation shield at 1.5 to 2 m, away from walls and pavement, mirroring ASOS siting as far as possible. Configure chrony against public NTP servers and log the clock offset each minute. logger.py reads the sensor every 10 s, writes one-minute mean, min, max and clock offset to a daily CSV, and pulls the station's latest observation from api.weather.gov alongside it. Ship a systemd service and timer, log rotation, and a health check that writes a heartbeat file. Then run for 14 days and produce residual.parquet: sensor minus station per minute, with hour-of-day and cloud cover from METAR. Note in sensor_spec.md the parts cost, power draw, and how to reproduce the install on a second Pi.

Using residual.parquet and the latency ledger, build a model that, at any minute in the final six hours, outputs the probability of each settlement bucket. Inputs: current sensor reading corrected by the hour-of-day residual, running daily max so far, latest METAR T-group, forecast high from the NWS point forecast, minutes to window close. Use an empirical distribution of remaining rise given time of day and current gap, fit on the first 10 days, tested on the rest. Build an identical model that drops the sensor input and uses public data only; this is the control. Report Brier score and log loss for both on the held-out days, plus reliability diagrams. Save both fitted models with their training-day list so step 5 can load them unchanged.

Write paper_engine.py, scheduled every minute in the final six hours before each chosen contract resolves. It reads the order book over websocket, computes market-implied probability from the mid, and the sensor-arm and control-arm probabilities from model.py. A paper buy fires only when model probability minus ask exceeds fees plus 3 percentage points. Caps: 50 USD paper notional per contract, 200 USD paper daily loss stop, 1,000 USD total paper drawdown halts everything. Separately, log every outcome trading at 99c or above in the same window, simulate a resting limit buy at 99c with queue position assumed last, and record its paper result after resolution. Every fill pays the venue's published fee and the spread. Write to paper_fills.parquet. The code must contain no order-placing call; assert that no trading credential is loaded.

After at least 30 resolved paper contracts, compute for each arm: Brier score, log loss, number of trades, net P&L, net expected value per trade with a bootstrap 95% interval (10,000 resamples by contract day). Compare sensor arm to control arm. For the 99c ledger, compute break-even win rate after fees, observed loss count, and the expected value per fill with interval; pull the venue's history of 99c favorites that lost to estimate tail frequency beyond your sample. Compute the Wasserstein distance between week-1 and final-week sensor residuals and between paper-period and backtest-period price distributions. Answer the falsifier directly: does the public intra-hour feed move price as fast as the sensor? Write results.md with a GAPS section: every claim from the source posts and from your own steps, marked verified, unverified or false with the evidence file. State the real-money gate result in one line; never recommend live trading if the interval includes zero.

You are auditing a finished paper study of sensor-settled prediction-market contracts. Open settlement_map.parquet, latency_chain.md, residual.parquet, paper_fills.parquet and results.md. List every factual claim in results.md, one per line. For each, mark verified (cite the file and row or computation that proves it), unverified (say what data would prove it), or false. Specifically check: that each traded contract's station and rounding rule match the rules text; that no feature in the model uses data after the prediction minute; that fees and spread were charged on every fill; that the control arm traded the same windows; that the 99c tail estimate uses more than your own sample; that the Pi clock stayed within 1 s; and that the source claims (100K+ USD from a dorm station, 75 trades per hour at 99c) are labeled unverified anecdotes, not evidence. Then list missing pieces: contracts never resolved, stations without one-minute data, days with logger outages. Rank problems by verdict impact. Fix the top three now by re-running the relevant computation, and report the before and after numbers. End with what you could not fix and why, and restate the real-money gate result.