How IL9Cast generates its forecasts
The Markets page aggregates real-time probabilities from two major prediction markets: Manifold Markets (community-driven) and Kalshi (real-money exchange). This provides a live, crowd-sourced forecast updated automatically as new trades occur.
Manifold Markets (40% weight):
Kalshi (60% weight):
Within Kalshi's 60% weight, we use three price signals:
1. Last Price (42% overall = 70% of Kalshi's 60%)
2. Midpoint (12% overall = 20% of Kalshi's 60%)
Thin-Market Fallback (Midpoint & Liquidity)
When a candidate has no yes-side bids (yes_bid = 0), the standard midpoint formula (yes_bid + yes_ask) / 2 produces a meaningless number — it averages zero against the ask, massively inflating the result. In these cases, both the Midpoint and Liquidity-Weighted components fall back to the candidate's last trade price instead.
Example — Mike Simmons: Simmons has virtually no buy-side interest on Kalshi. His order book might show yes_bid = 0, yes_ask = 19, last_price = 1. Without the fallback, the midpoint formula would compute (0 + 19) / 2 = 9.5%, and the liquidity-weighted price would land around 9.0% — suggesting nearly 10% support for a candidate trading at 1 cent. With the fallback, both Midpoint and Liquidity correctly report 1%, matching his actual last trade. The spread-based liquidity adjustment is also skipped entirely because there is no real two-sided market to analyze.
3. Liquidity-Weighted Price (6% overall = 10% of Kalshi's 60%)
A real incident during this race perfectly illustrates why IL9Cast's multi-source approach is more reliable than watching a single market.
What happened: A trader on Kalshi bought Laura Fine yes-contracts aggressively, pushing the last trade price all the way up to 30%. Then they stopped. The market maker immediately placed no-orders at 16%, while existing yes-orders sat unfilled at 14%. For quite a while, Kalshi's displayed probability showed 30% — based solely on that last executed trade.
The reality: The actual market consensus was a 14-16% spread. No one was willing to buy above 14%, and no one was willing to sell below 16%. The 30% price was a single trade artifact, not a reflection of genuine market sentiment.
IL9Cast's response: Our aggregated probability showed the upward price movement somewhat — the trade did contain real information — but stayed grounded around the spread rather than jumping to 30%. Here's why:
The result: while Kalshi briefly showed Laura Fine at 30%, IL9Cast accurately reflected the true market state — modest upward movement constrained by the actual bid-ask reality. This is exactly the kind of thin-market artifact our aggregation approach is designed to filter out.
The takeaway: Single prediction markets can be misleading when liquidity is low or a single large trade occurs. By combining multiple price signals and applying dampening, IL9Cast gives you a clearer, more stable view of the race.
When a Kalshi last trade price falls outside the current bid-ask spread, its weight in the aggregate is automatically reduced. This prevents stale or outlier trades from disproportionately influencing the forecast.
yes_bid = 0 (no buy-side orders), the throttle does not activate. These cases are already handled by the separate thin-market fallback that uses last_price directlyUsing the Laura Fine example above: with last_price at 30% but the spread at 14–16%, the throttle would shift weight toward the spread-based components (midpoint ~15%, liquidity-weighted ~15%), keeping the aggregate grounded near market consensus instead of being pulled toward the 30% outlier.
Final probabilities are lightly normalized to prevent excessive drift while preserving raw market values:
To produce clean, readable trend lines, the chart pipeline applies multiple smoothing layers:
Historical snapshots are saved with every update and aggregated hourly for clean trend visualization.
The Markets page includes a results heatmap showing the derived probability of every possible 1st-place and 2nd-place finish combination. Since prediction markets only provide marginal win probabilities (P(candidate wins)), we derive the joint probabilities using conditional probability:
Intuition: If candidate A wins (with probability P(A)), the remaining candidates compete for 2nd place. We assume their relative win probabilities determine who finishes 2nd. So candidate B's chance of finishing 2nd, given A won, equals B's probability renormalized among all non-A candidates: P(B) / (1 − P(A)). Multiplying by P(A) gives the joint probability of A finishing 1st and B finishing 2nd.
Key assumption: This treats candidates as independent — it assumes that A winning doesn't change the relative ordering of the remaining candidates. In practice, ideologically similar candidates may cannibalize each other's support, which would make some 2nd-place finishes more or less likely than this model predicts. The heatmap is a first-order approximation, not a full correlated model.
Reading the heatmap: Rows represent the 1st-place finisher, columns represent the 2nd-place finisher. The diagonal is empty (a candidate can't finish both 1st and 2nd). Brighter blue cells indicate higher probability pairs. The most likely 1st/2nd combination is highlighted at the top.
Our precinct-level election model is built in Stata and produces precinct-by-precinct projections displayed on an interactive map on the Model page. The full methodology is documented in the paper linked below.
Read the full methodology (PDF) →
Note: The PDF documents the February 2026 model architecture. See v3.1 updates below.
Key changes from the February model:
The Money page aggregates campaign finance data directly from the Federal Election Commission's public API. This gives us real-time insights into total raised, cash on hand, spending patterns, and grassroots support metrics for all candidates in the race.
All fundraising data is sourced from official FEC filings, currently hardcoded from Pre-Primary reports (coverage through Feb 25, 2026; filed March 5, retrieved March 6, 2026). The original data was pulled from two FEC API endpoints:
GET /v1/candidate/{candidate_id}/totals/Each candidate is identified by their FEC committee ID. For example:
Note on Cash on Hand: The FEC-reported COH (Line 27) may differ slightly from total receipts minus total disbursements due to beginning balance carryforward, loans, refunds, and other adjustments. We use the FEC-reported figure as the authoritative value.
The "Small $%" metric measures grassroots support by calculating what percentage of a candidate's individual contributions come from donations under $200. This is the FEC's standard definition of small-dollar/grassroots fundraising.
Calculation formula:
The FEC breaks down individual contributions into two categories:
Why we use individual_contributions as the denominator: Total receipts include PAC money, party transfers, and other non-individual sources. To accurately measure grassroots support, we only consider money from individual human donors.
Real example from Kat Abughazaleh's FEC data:
This means 70.2% of Kat's individual donations came from contributors giving less than $200 — a strong indicator of broad grassroots support.
Burn rate and raise rate measure monthly spending and fundraising velocity during the most recent FEC filing period. Both use period-specific figures from FEC Form 3, Column A — not cumulative totals.
Why period-specific? Cumulative totals include money raised and spent over the entire campaign lifecycle. Period-specific figures capture the campaign's current spending and fundraising velocity, which is more useful for projecting forward to election day.
Important distinction: A candidate's burn rate may exceed their raise rate even if cumulative total_raised exceeds total_spent. This indicates the campaign is currently spending faster than it's raising — drawing down reserves built up earlier in the cycle.
The fundraising data is currently hardcoded into the application using Pre-Primary FEC filings through February 25, 2026 (filed March 5, retrieved March 6, 2026). The data is static and doesn't require live API calls.
This approach provides instant page loads (no 2-3 second API delays) while ensuring the displayed data remains accurate.
The fundraising chart uses a dual Y-axis approach to compare two fundamentally different metrics:
The spent percentage bars are nested inside the blue fundraising bars (same X position, narrower width) to save horizontal space while keeping both metrics independently readable on their own scales. This nested-bar technique is implemented using Chart.js with stack: 'combined' and stacked: false to center both bars at the same position without summing their values.
IL9Cast is a pretty lean operation — a single Python app running on Railway that does everything from fetching market data to serving the website. Here's how it all fits together.
We run on Railway, which is a platform-as-a-service that deploys straight from GitHub. Every time we push code to the main branch, Railway automatically builds and deploys a new version using Nixpacks (their build system). The whole deploy cycle takes about 30 seconds.
The app runs behind Gunicorn, a production-grade Python WSGI server. We use the --preload flag, which is important — it loads the app once in memory before forking workers, so our background data collector only starts a single thread instead of duplicating itself across workers. Without that flag, you'd get multiple scrapers all writing to the same file at the same time, which is a recipe for corrupted data.
Here's the key configuration from railway.toml:
That restart policy is our safety net. If the app crashes — maybe a dependency breaks, maybe Railway has a hiccup — it'll automatically restart up to 10 times before giving up. In practice, it almost never needs more than one.
Railway containers are ephemeral by default — when the app redeploys, everything on the filesystem gets wiped. That's fine for code, but our historical data needs to survive between deploys. So we use a Railway persistent volume mounted at /app/data.
When the app boots up, it runs a path resolution function that checks, in order: /data, /app/data, then falls back to a local data/ directory. This means the same code works on Railway (where the volume lives at /app/data) and on a developer's laptop (where it just uses the local folder). No environment variables, no conditional imports — just a directory check.
You might wonder why we're storing data in a flat file instead of PostgreSQL or SQLite. Honestly? For our use case, JSONL is better.
JSONL (JSON Lines) means one JSON object per line. Every 3 minutes, the scraper appends a single line to the file — that's it. No connection pools, no schema migrations, no ORM overhead. The file is human-readable (you can literally tail it to see the latest data), and if a line gets corrupted, every other line is still perfectly valid. Try saying that about a SQLite database after a partial write.
The append operation is actually a bit more careful than a simple file write:
historical_snapshots.jsonl.tmpos.replace() swaps the temp file into place in a single filesystem operation. If the app crashes mid-write, either the old file or the new file exists — never a half-written messAt 480 snapshots per day (~3 KB each), the file grows at roughly 1.4 MB/day. After a full election cycle, we're looking at maybe 70 MB total. That's nothing — your phone has thousands of times more storage. A database would be overkill here.
Every 3 minutes, a background thread wakes up and runs our collect_market_data() function. Here's what happens in those few hundred milliseconds:
last_price, yes_bid, and yes_ask. Same 10-second timeout.If both APIs fail (say Manifold is down and Kalshi returns an error), we skip the snapshot entirely. Bad data is worse than missing data — the chart just won't have a point for that 3-minute window, and the gap detection handles it gracefully.
Running a background task alongside a web server sounds simple, but there's a subtle gotcha. When you run Flask locally, you get one process — easy. But Gunicorn can spawn multiple worker processes, and each one would try to run its own scheduler. That means two workers = two scrapers = double the data (and double the API calls).
We solve this two ways depending on the environment:
BackgroundScheduler, which runs the job in a background thread within the single Flask process.sys.argv[0] and instead spins up a plain threading.Thread in daemon mode. The --preload flag ensures this thread is created once in the master process before workers fork, so only one thread ever exists.When you load the Markets page, your browser hits /api/snapshots/chart?period=1d (or 7d or all). Here's what the server does before sending data back:
The RDP algorithm is actually kind of elegant. Imagine drawing a straight line from the first data point to the last. Now find whichever intermediate point is farthest from that line. If it's farther than epsilon, that point matters — keep it, and recursively check both halves. If it's closer than epsilon, the whole segment is "flat enough" to represent with just the endpoints. It's O(n log n) on average and perfectly preserves peaks, valleys, and inflection points while throwing away the boring flat stretches.
The chart itself is rendered with Chart.js using a time-scaled x-axis. The data comes in as {x: timestamp, y: probability} pairs, and Chart.js handles the rest. A few important settings:
cubicInterpolationMode: 'monotone' setting. Regular cubic splines can "overshoot" — if a candidate goes from 60% to 62%, a regular spline might draw a curve that briefly dips to 59% between the points. Monotone splines guarantee the curve never exceeds the actual data values. No fake dips, no fake peaks.Intl.DateTimeFormat. This handles daylight saving transitions automatically — no hardcoded offsets.A few things have bitten us before, so we built defenses:
--preload + sys.argv detection ensures exactly one scraper thread exists in production.The whole app runs on five Python packages:
No NumPy, no Pandas, no heavyweight data libraries. The EMA, RDP, and aggregation math are all hand-written in ~100 lines of plain Python. For a project that processes a few hundred data points, there's no reason to import a 30 MB library.
IL9Cast's prediction market aggregation is maintained by Ryan McComb, a student at ETHS, as an educational project to help voters understand real-time sentiment in the Illinois 9th Democratic Primary race.
For questions about the market aggregation methodology or to report data issues, please reach out directly.
