Sources and methods

Reference data and dated rule audits

The current reference describes game 1.3.0, Balance 25, Steam build 25738032.

• The reference comes from a locally extracted copy of the game. It includes stats, ability text, variants, evolution links, and resource identities.
• The website builds those documents ahead of time. A reference page does not fetch a player account or game server when you open it.
• Mechanics and guides also use checked game code, published developer notes, and dated observations. A current catalog does not certify every older rule audit as current.
• The original How to Play and rank guide retain build 24079270 / Balance 12 evidence. Their detailed search and rank rules describe that audit; the current catalog header is not a new verification of those rules.
• Selected reference pages add dated tactical notes. They distinguish a checked rule from conditional advice, not a measured best strategy.

Where the public records come from

• The game's public API at api.batomon.app supplies server configuration, trainer-selection records, and owner-scoped public profiles. The adapter requests one public profile owner at a time. It does not use your game login.
• The public Batodex leaderboard helps discover ranked players. Public Batodex profile HTML can supply a profile when the API does not supply a usable record. Missing records do not become invented runs or zero-result claims.
• Leaderboard ranks describe the latest imported snapshot, not a live result for every account. Player profiles can include reported rank, trainer totals, recent matches, and observed teams. A missing field or empty history means the source did not provide that data.
• Trainer selection rates use public offer and selection records. Entity and pair statistics use observed public profile rounds. An appearance on a team is not a shop offer or a gift pick rate.

How Comps summarizes teams

The current algorithm is comps-v2.2. Its inputs are public ranked final-team observations, not private Companion matches.

1. Select up to 5,000 recent ranked candidate runs by start date and the requested MMR band. Runs without a terminal result must have a recent source observation. Require the last observed round to match the reported round reached, with three to six recognized units.
2. Find recurring three-unit cores and assign an eligible board to at most one archetype. Summarize frequent units and earlier observed phases for the assigned runs. The grid is a representative composition, not verified board coordinates or a recommended exact placement.
3. The displayed 10-win finish rate divides qualifying 10-win runs by terminal runs in that archetype. The algorithm treats at least 10 wins or 5 recorded losses as terminal. This observation rule is not the game's life-loss rule.
4. For tier scores, average terminal results within each player first, then average players equally. Pull each archetype's finish rate and capped-wins fraction toward the sample baseline with 20 player-equivalents. The score uses 70% finish-rate difference and 30% capped-wins difference. Wins above 10 do not add score.

A qualified archetype needs 40 runs from 25 players, including 25 terminal runs from 15 players. Letters appear only with at least 8 qualified archetypes. The default 30-day view can widen to 90 days when that comparison is too small; check the displayed window.

Inspect the current sample. Item ideas follow effect/type compatibility, not measured purchase success. Team Builder creates an editable plan; it does not calculate your win probability.

What the sample cannot establish

• Public histories are a subset of players and runs. Missing rounds, delayed profiles, selection bias, and small samples can change the result.
• The displayed raw finish rate counts runs. The tier score balances players. Neither is a forecast of your next battle.
• An observed team or trinket can accompany success without causing it. Player skill, opponents, earlier choices, and unreported modifiers also matter.
• Public runs can lack explicit build or balance fields. Date-based attribution is an inference. Comps maps recognized units to the current catalog; that does not prove every observed board used the current patch.
• Use the window, sample size, source age, and patch labels together. Unknown and stale data should not become a confident strategy claim.

Public statistics and private Companion data

• Public pages need no account. A public pseudonymous game owner ID is not a Steam ID or a Companion account ID.
• Companion uses a separate email/code link and explicit Match uploads consent. Private reports are visible only to the linked account.
• Private Companion matches do not feed public Comps or public profile-round statistics. Local prediction does not upload its inputs or trial results.
• Do not put private credentials in a build code or feedback report. Read the privacy policy and opt-out instructions for complete details.

Updates, outages, and corrections

• Background jobs normally import the leaderboard once daily, refresh queued profiles, and calculate public aggregates twice an hour.
• A source-fetch timestamp is not a calculation timestamp or a new game release. Cached pages can also lag those jobs.
• Profile-round data has a longer age limit than direct trainer records. A fresh status shows recent observation, not complete population coverage.
• Outages, rate limits, and schema changes can delay updates. Validation rejects unusable payloads; no fixed refresh interval guarantees new data.
• A new game build needs a catalog import and source review. Dated audit IDs and source hashes stay unchanged as history. New reviews add evidence rather than renaming an old audit.
• Check Game data for current source status and release notes for catalog changes. Use the site feedback control to report a mismatch, with the page URL and visible rule or sample context.

This explanation describes the implementation reviewed on 6 October 2026. It is not a live health check.