Live pipeline state. The headline question this answers is what is complete and what is not — every stage reports its own coverage, so nothing is inferred.
Stage coverage per-app completeness
Channel attribution new games found, last run
Newest captures inside the report window
Reconciliation state. Blocking stages gate an app
from being reported at all; optional stages never do — a failure there
becomes unknown and retries on a decaying schedule.
Stages
Backlog candidates discovered but not yet detailed
Which channel earns its requests. Charts are expected to contribute ~0 new games — they rank by installs, and a new game has none. That is why the watchlist exists.
Attribution by run
The discovery engine. A publisher page lists every app they own — including one shipped yesterday with zero installs — so this, not the charts, is what finds new releases.
Publishers ranked by new games found
Long-tail search terms, seeded by hand and grown by
suggest(). Head terms return only established apps; narrow
queries have few enough competitors for a young app to rank.
Query list yield-ranked; low performers demote to weekly
Captured games. The capture window (60d) is wider than the report window (14d) on purpose — a game discovered late is still stored, so it is never permanently lost.
Add or diagnose a game paste a Play URL or appId
Adding a game also subscribes to its publisher, which is the part that keeps paying off: an unknown studio's first game is invisible to every automatic channel, but once the publisher is watched, every future release from them is caught on day one.
Browse
SDK and publishing stack, extracted from each game's privacy policy. Policies are deduped by URL because publishers reuse one across a whole catalogue.
Detected partners
A new game has no ratings by definition, so ranking by rating-count delta can only ever surface games that are already established. What moves first is the install bucket — Play reports installs in coarse steps, and crossing one is a game's earliest public signal. Momentum uses whichever signal is actually available: bucket promotions first, then ratings, then reviews.
Rising ranked by momentum, strongest signal first
Not yet measurable observed too briefly to say anything
These are not flops — they are games we have not watched across two days yet, which is a different statement and deserves to look different. They become measurable as snapshots accumulate.
Reports are rows, not code. Adding one is an
insert; widening a window is a WHERE clause. Neither
requires re-crawling anything.
Saved reports
Run history with request and error counts. A run that trips the circuit breaker on sustained 429/403 stops rather than digging deeper — tomorrow's run retries for free.
Runs
The hub is the control plane. A client registers, heartbeats, and pulls whatever configuration it is given — role, accepted work, throttle, proxy and caps all live here, and apply on the next heartbeat with no restart. Installing a client is therefore "register and run", with nothing to configure on the machine itself. Work is still pulled, so a client behind NAT needs no tunnel.
Clients click a row to configure it
Configure
Pushing bumps the client's config version; it applies on the next heartbeat with no restart. Capabilities are derived from accepts × channels, so narrowing them immediately stops that client being leased work it should not run. Proxy credentials are stored on the hub and are redacted everywhere they are displayed.
Activity report per client, by window
Task queue by type and state
Rejected results validation failures, requeued
Activity append-only client event log
Queue work for clients. Each template expands into one task per unit of work, and the capability field decides which clients are eligible — an old client is never handed a task it cannot run. Tasks are pulled, never pushed: the hub never connects outward, so a client behind NAT works with no tunnel.
Enqueue from template
Queue
Hub-owned settings. Saving bumps the config version and every client converges on its next heartbeat — no restart, no redeploy. Network settings (proxy, throttle) are deliberately client-owned and are not editable here.
Windows capture must stay wider than report
A game found after the report window still gets stored, so it is not
lost. Narrowing capture below report is rejected — seen_apps
never re-fetches a rejected id, so those games would be erased rather
than merely deferred.
Categories chart sweep — harvests publishers, not games
Keyword taxonomy classifier tags + search seeds
Reclassifying re-derives tags from stored text — no re-crawl. Live data showed store descriptions are keyword-stuffed, so min score 2 stops a single passing mention from inventing a mechanic.
Partner tokens matched against privacy-policy text
Raw JSON for anything the forms above do not cover
Roles are cumulative: a viewer reads reports, an editor also curates keywords and publishers, an operator also runs tasks and clients, an admin also manages people. The last active admin cannot be demoted, deactivated or deleted, so the hub can never be locked out of.
Add a user
Users
Roles what each one grants
Audit log who changed what
Build progress against the plan, with the evidence behind each claim.