skeleton — pre-regs locked 2026-04-25 · paper Phase 1A targets 05-01
Port of Prophecy FORGE to event-driven raw asyncio. Reacts to Polymarket WebSocket orderbook deltas in 200-500ms. BUY YES + BUY NO same conditionId when sum < $1.
Prophecy FORGE: $686 lifetime / 4,206 trades at 5-min cadence. Expected +30-50% capture vs slow path.
50.0%
n=4
−$8.33
insufficient n
When NOAA AviationWeather publishes a fresh METAR, scanner re-evaluates active buckets via TrajectoryModel v1 and BUYs YES on cheap mispriced buckets. Edge = lag between raw METAR publish and Wunderground display update.
3 witnesses: HondaCivic2 +28pp edge n=103, Joe/Henry pair +13.6pp n=305, WeatherTraderBot +6.7pp · single-regime sample
7.7%
n=26
−$122
no edge detected
hermes_forge backtest + /quant-risk + /quant-researcher + /quant-validator.hermes_vanguard backtest (independent validator dispatch).hermes_forge skeleton + shadow mode.hermes_forge penny-scale live ($1/trade × 100-300 pairs).hermes_vanguard skeleton + penny live.Why a separate microservice?Hermes runs raw asyncio + persistent WebSocket + event-driven scanners. APScheduler (used by weatherbot) doesn't compose with this model. Separate process = crash isolation, independent restart, independent logs — same DB, same git repo.
Why two strategies? They share one event loop and one execution layer. hermes_forge is the validated mechanism (de-risks the microservice infrastructure). hermes_vanguard is the speculative bet (METAR trajectory front-running) that rides on the debugged platform.
Latency target: 200-500ms METAR-publish → order-submitted. Polygon block time (2s) is the floor — Hermes aims to be FIRST in the next block, not faster than physics.
Skeleton at: /opt/weatherbot/src/weatherbot_hermes/. Master plan: docs/strategies/foresight/05_MASTER_PLAN_v2.md.