Can we predict attacks?

TLDR — how we predict attacks: an attack fires the moment a faction's campaign hits full points — points == points_max, exactly, within minutes. So the forecast is just arithmetic: eta = (points_max − points) / rate, with a day-of-week correction to the pace. Replayed against all ~160 recorded wars as if it were running live, it's typically 3–4× closer than just guessing the historical average — clearing the pass mark we wrote down before testing — and ships on the dashboard as an assault heads-up line. It never becomes a clock: the window is ~21h wide a day out, ~5h wide two hours out. How the defend side compares →

Attacks are deterministic. An attack on a faction's homeworld fires within minutes of that faction's campaign reaching full points — points == points_max, the exact integer. Every one of the 925 recorded attacks targets region 11, the enemy homeworld; none fires early.

There is nothing fuzzy to estimate about the trigger itself. It's a constant the game already tells us, stored in h1_season.points_max.

The trigger is a point, not a band

Read at daily resolution, attack starts appear spread across a band of liberation values — a median near 96%, most firing somewhere above 90%. That spread belongs to the sensor, not the game: h1_status runs at roughly one bucket per day for 156 of the 160 seasons, so the campaign state read at an attack's start can be up to 24 hours stale, and a hard threshold viewed through a lagging sensor smears downward. Sorting the same 925 attacks by how fresh the reading was makes it plain:

The "band" was a staleness gradient. Read fresh, the trigger is a point.

The thirteen freshest readings are more convincing individually than any median, because the residual shortfalls scale with how early the reading was taken:

Twelve of thirteen sit within 0.1% of full. Season 20's Bug campaign was 46 points short of 763,240 sixty-two seconds before the attack began — a sensor catching the last seconds of a climb, not a threshold with slack in it. The six sub-100% rows are all pre-S157 seasons whose whole campaign is covered by 13–43 buckets; their shortfall tracks their reading age, exactly as a hard threshold predicts.

How soon after reaching full points?

For the four seasons with 15-minute resolution, the gap between the first bucket at full points and the attack's start is 1 to 14 minutes, median 3.0 (n = 7). Since a bucket can be up to 15 minutes wide, these are upper bounds. The trigger is effectively immediate.

Can we forecast the next one?

With the trigger known exactly, forecasting an attack stops being a question about the trigger and becomes a question about pace:

eta = (points_max − points) / rate

Everything on the right-hand side except rate is known exactly and in real time. So the entire forecasting problem — and the entire error budget — lives in estimating how fast a campaign is gaining points.

Measured, and it works. We replayed that formula against all 925 recorded attacks as if it were running live — always forecasting each war using only the wars before it, never letting it peek at its own future. Its typical miss, next to the dumbest possible guess (always saying the historical average):

That's 3–4× better across the board, and the window it draws is genuinely narrower than the raw spread of history — both requirements of the pass mark this project wrote down before running any model. For scale: the best defend model ever built got only ~1.5× better than the dumb guess and failed that mark. This is the first thing in this project to clear the mark it was measured against, and it does so because the trigger is exact — the model is only forecasting pace, not guessing at a threshold. (The full statistical scorecards live in the investigation handoff and re-print on every run of 10-attack-eta.mjs.)

The forecast is not available at every moment. Roughly 38–47% of moments emit nothing at all, because a stalled or retreating front (rate <= 0) gives no arrival time. A front that is not moving has no ETA, and the honest output is silence.

What a player would actually see

The intended use is a heads-up, not a countdown, so we scored it like an alarm — and wrote down the two pass marks (70% and 80%) before running it:

The line shows up on the dashboard whenever the middle estimate falls under 48 hours.

Why 48 and not 24. The threshold was 24h first, and moving it out improved everything at once: the alarm fired before more attacks, cried wolf less, and its "sooner than X" claims came true closer to the honest 50% a middle estimate should hit (it moved from ~46–53% to ~50–54%). The reason is the data itself: for most of recorded history the campaign state updates only about once a day, so a 24-hour warning window is exactly where the input is blurriest. And the window does tighten as the attack approaches — this is the model's own output, on the moments a player would actually see:

A day out the window is ~21 hours wide; a couple of hours out it is ~5. It never becomes a clock. The width tracks the estimate itself, so the display goes 17–38h → 8–19h → 1–6h and stops. Curiously the relative uncertainty is slightly worse close in — roughly 1× the estimate a day out, 2× a couple of hours out — which is the daily-bucket staleness biting hardest when little remains to conquer.

While the assault runs

Once the assault fires, the question flips from when to how it ends, and the event card switches to the outcome verdict: at the average pace since the assault started, does its bar fill inside the 48-hour timeout? On track → "Taken ~12h"; behind → "Fails" (the countdown already shows the loss time).

The verdict is unusually decisive on assaults. Splitting every recorded moment by what the verdict said at the time (8 assaults with minute-level history so far):

An on-track reading has never been followed by a failed assault — at any stage — while a behind reading fails about two-thirds of the time early and always past 60% elapsed. Read this as a strong direction, not a precise percentage: one assault contributes many readings, and only 8 assaults have this kind of history so far. Folding it into the counterattack clock is #487, waiting until ~30 assaults have been recorded at this detail.

The sector ETA — the same arithmetic, one boundary early

The faction cards' sector view shows an ETA ~9h line toward the next sector boundary — the same remaining ÷ pace computation as the assault ETA (literally the same code path, paceEtaHours in attackForecast.mjs), aimed at the next points_max / 10 step instead of the campaign's end. Same 24-hour rate window, same day-of-week correction, same staleness anchoring.

Two honest differences from the assault window:

• One number, no range. The measured ratios that turn the assault estimate into a trustworthy (10–25h) window were checked against one target only — full campaign completion. Nobody has yet measured the equivalent for sector boundaries (that needs more high-resolution seasons, #484), and a range we haven't measured is a range we don't show.
• Hidden during any active event for that faction. Defends freeze the campaign bar; during an assault the campaign is already complete.

In the last sector the next boundary is the campaign end — exactly the target the assault forecast was measured against — so the card switches to the full assault window rather than showing an unmeasured single number for the same thing.

Why the window is lopsided

The dashboard shows the forecast as ETA ~14h (10–25h) — a median with an asymmetric range, never a symmetric ±. That is not a style choice. The skew is baked into the arithmetic, twice over.

Division skews time. The forecast is arrival = points remaining ÷ pace, and division treats the two directions unequally. Pace swings are symmetric — players arrive, players leave — but their effect on the arrival time is not:

Speeding up can at best push the arrival toward zero — it can never save more than the hours already on the clock. Slowing down has no such limit: as pace approaches zero, the arrival time grows without bound. Drag the pace and watch the curve do it:

Surges are capped, stalls are not. The second half of the skew is supply. For an attack to land much earlier than forecast, extra players must show up — and a front can realistically double its pace on a good evening, rarely more. For it to land much later, players only have to leave: sleep, weekdays, a juicier event on another front. Showing up has a supply limit; leaving does not.

The measured history agrees: across 160 seasons, when the raw arithmetic said "X hours", reality typically landed between ~0.85×X and ~2.3×X depending on how close the campaign was to completion — small early misses, large late ones. A ± label would promise a symmetry the game has never once delivered; the (10–25h) range is the same information, told honestly.

node --env-file=.env.development scripts/analysis/10-attack-eta.mjs
node --env-file=.env.development scripts/analysis/12-faction-players-eta.mjs