Why a Banner Tracker Needs an Evidence-State Model

Live-service game guides have a difficult data problem: the most searched question is often the least stable one. A player wants to know the current banner, what comes next, and when the phase changes. Those answers can become wrong within hours, while community speculation can look almost identical to confirmed information in a feed.

I approached this as a state-modeling problem rather than a stream of blog posts. The key is to store what is known, how it is known, and when the snapshot was rebuilt as separate fields.

Use explicit evidence states

A banner record should not be either “published” or “missing.” It needs an evidence state:

confirmed
  official notice or in-game Convene data supports the lineup and dates

watchlist
  a version mention or community signal exists, but the lineup is not official

historical
  a completed phase retained for rerun and sequence research

This prevents a generic version-number mention from silently becoming a future banner page. The page can still say that the next official update is pending, but it should not invent characters, weapons, or dates to fill an empty card.

Separate the live snapshot from history

The homepage should read from a small current-state object:

{
  "version": "3.7",
  "phase": 2,
  "featured": ["Suoming", "Lucilla", "Lynae"],
  "endsAt": "2026-11-11",
  "nextStatus": "pending-official-reveal",
  "snapshotDate": "2026-10-23"
}

History belongs in an append-only collection. That separation makes it harder for an update script to overwrite the rerun evidence players need later. It also lets the interface answer two different questions cleanly: “What is live?” and “How long has this character been absent?”

Make uncertainty visible in the interface

The data model only helps if the UI exposes it. A useful next-banner card can show:

• Pending official reveal instead of a guessed lineup
• the next reliable checkpoint
• the source type required to upgrade the record to confirmed
• links to countdown, schedule, history, rerun, and pity pages

That gives the user somewhere useful to go even when the next lineup is unknown. Empty information becomes a routing decision instead of an invitation to speculate.

Rebuild static pages from one source of truth

A static tracker can still handle frequent changes. The build reads the current snapshot and history data, generates the homepage and focused pages, then writes the snapshot date into visible text. The important content remains in the original HTML, so search engines and readers do not need client-side JavaScript to discover the current answer.

The browser can handle lightweight personal state separately. Pity notes or planning choices can remain local without pretending to sync with the game account. The published banner facts stay deterministic and reviewable.

I used this approach in WuWa Banners, an independent Wuthering Waves banner tracker with current and next status, countdown, history, rerun context, pity guidance, and pull-planning routes.

The broader lesson applies to any fast-changing guide: model uncertainty as data. Keep live state separate from history, record the snapshot date, and require stronger evidence before a watchlist signal becomes a confirmed answer.