How PokeTeamOn turns a team into explainable findings.

1. Context comes first

A team cannot be interpreted correctly without context. Generation and format determine which rules and source records are relevant, while a set's species, moves, item, ability, nature, EVs, IVs, level, and Tera Type affect what the tool can observe. PokeTeamOn therefore keeps the selected context attached to analysis instead of treating every team as if it belonged to one universal rule set.

Context also limits conclusions. A fact that is valid for a supported local dataset is not automatically a statement about every historical generation, unofficial format, unusual ruleset, or future metagame update. When a required source record is unavailable, the safer result is partial or unsupported rather than a fabricated answer.

2. How the Analyzer works

The Analyzer reads the team document already configured in the Builder and derives factual set-level and team-level observations. Its current contracts include calculated stat profiles, selected-move metadata, offensive category distribution, speed distribution, priority access, STAB access, EV and IV observations, and other structural evidence exposed by the supported analyzer layer.

These observations are descriptive. PokeTeamOn does not convert them into an opaque Team Health number, a weighted competitive score, or a win probability. A repeated weakness, for example, is evidence about the structure of the team; it is not proof that the team loses a matchup. Likewise, access to a coverage move is a fact about the selected set, not proof that the Pokémon safely answers every opponent that shares the targeted typing.

The Analyzer is deterministic for the same supported input and local source state. Its purpose is to expose what is present in the team and make that evidence available to later diagnostic steps.

3. How Stress Tests work

Stress Test evaluates explicit scenarios rather than inventing an opponent. The current orchestrator accepts one to eight selected scenario runs. Each run is built from a known archetype and any parameters required by that archetype, such as an explicit stat threshold or target typing.

The scenario engine evaluates only the declared checks. The evidence layer then aggregates those results into categorical states and preserves the assumptions that produced them. Thresholds and target types remain visible inputs; they are not silently replaced by hidden model preferences.

A stress result therefore means, in effect, “under this stated condition, the supported evidence looks like this.” It does not mean “the next opponent will do this,” and it does not estimate how often a scenario appears on the ladder. Stress Test returns categorical evidence, not a team score or win probability.

4. How Minimal-Change Repair works

Repair begins with an explicit problem or stress target. PokeTeamOn generates deterministic candidate changes inside the supported repair contract, evaluates the effect of those candidates against the same target, and preserves candidate order without turning that order into a competitive ranking.

The user selects which candidate to inspect. Automatic candidate selection is outside the contract. The selected result is a preview: the server does not silently apply the change to the team, persist a replacement, or claim that one candidate is universally “best.”

“Minimal change” means the repair tries to address the explicit failure with the smallest supported change set available to that repair path. It does not mean that every strategic problem can be solved with one edit, and it does not override the user's intended team identity.

5. How explainability is attached

Explainability is downstream of the result it explains. The Builder captures a supported Analyzer, Stress Test, or Repair response that has already been executed by the user, then passes that captured response into the explainability layer. The explanation path does not replay the source request merely to create an explanation and does not recompute a different source result behind the user's back.

Machine-readable evidence items retain traceable identifiers and reason codes where the source contract provides them. Explanation composition preserves the evidence relationship and carries assumptions or unsupported states forward instead of manufacturing new evidence.

6. Facts, assumptions, and uncertainty

PokeTeamOn deliberately treats these as different categories.

Facts are values or relationships directly established by the supported input and local source data: a selected move, a calculated stat under the entered set, a native typing relationship, a count, or the presence of a supported move or role signal.

Assumptions are conditions required to run a diagnostic check. An explicit speed floor is an assumption because the threshold comes from the scenario the user selected. A coverage target is also an assumption about what the user wants to test. The result can tell whether the supported team data meets that declared condition; it cannot turn the condition itself into a universal metagame truth.

Uncertainty and limitations appear when the supported evidence is incomplete, partial, or outside the implemented contract. PokeTeamOn prefers an incomplete or unsupported result to a confident-looking guess. The product does not infer hidden opponent sets, player intent, future turns, or unobserved information.

7. Basic Legality Check — scope and limitations

The Builder includes a basic legality layer. Its contract intentionally states that it is not a full format-legality guarantee. Supported checks include local structural rules, supported direct-ban information, and Gen 9 learnset compatibility where the required local source data is available.

A “pass” means the set passed the basic checks PokeTeamOn actually ran. An “incomplete” result means the available basic checks did not establish a full legality conclusion. Neither state should be read as a substitute for a complete tournament validator, every event-distribution rule, every historical mechanic, or every complex format interaction.

This distinction matters elsewhere in the product: Repair is not allowed to present a candidate as valid merely because it looks strategically useful if the supported basic legality layer identifies a conflict.

8. Data sources and versioning

PokeTeamOn uses local, pinned source snapshots rather than calling an external Pokémon API during normal browser use. Pinning a source makes the product more reproducible: the source identity and pinned snapshot are recorded in internal provenance metadata alongside the derived local files, and a data refresh can be reviewed as an explicit change instead of arriving silently.

PokeAPI api-data

The core local Pokémon data manifest identifies PokeAPI/api-data as an upstream source, used through a pinned local snapshot. The manifest records the source license as BSD-3-Clause and stores hashes for the derived local dataset files.

Pokémon Showdown format and ruleset source

The context layer records smogon/pokemon-showdown through a pinned local snapshot. The local source manifest records the license as MIT and keeps local snapshots of the relevant format and ruleset source material. Supported PokeTeamOn contexts reference this same pinned local snapshot.

Analyzer calculation dependency

The analyzer manifest records the @smogon/calc package as a pinned local calculation dependency. PokeTeamOn documents that dependency because calculated analyzer values should be traceable to a known pinned dependency snapshot rather than an unspecified moving target.

What “pinned” does and does not mean

A pinned snapshot improves reproducibility; it does not mean the snapshot is automatically the newest upstream data forever. A newer upstream rule, form, format, or mechanic can require a deliberate data refresh and regression review before PokeTeamOn reflects it. The selected format and supported-data boundary shown by the tool therefore remain part of every interpretation.

9. Credits and sprite provenance

PokeTeamOn is an independent project. Third-party source projects and Pokémon intellectual property remain attributable to their respective owners and contributors.

Core local Pokémon data is derived from the pinned PokeAPI api-data source described above. Supported format and ruleset context is derived from the pinned Pokémon Showdown source snapshot. The analyzer manifest also records @smogon/calc as a pinned calculation dependency.

Pokémon sprites

Low-resolution Pokémon sprites used as visual identifiers are stored locally. Their source repository is PokeAPI/sprites, stored as a pinned local snapshot. No sprite is fetched from an external service at browser runtime.

The source repository's license file states that image contents are Copyright The Pokémon Company and also distributes the repository collection under CC0 1.0 Universal. The same source material warns that third-party rights are not automatically cleared by that distribution. PokeTeamOn therefore does not claim that these Pokémon images are original PokeTeamOn artwork or that Pokémon copyright or trademark rights have been waived.

Pokémon and related names, characters, artwork, and trademarks belong to their respective owners. PokeTeamOn is not affiliated with, sponsored by, approved by, or endorsed by Nintendo, Game Freak, Creatures Inc., or The Pokémon Company.

10. What PokeTeamOn does not claim

PokeTeamOn is a debugging and decision-support tool, not a battle-outcome predictor. It does not claim to model player skill, hidden opponent choices, future turns, ladder usage frequency, every unusual set, or every strategic interaction. It does not return a win probability, and current Analyzer, Stress Test, Explainability, and Repair contracts do not depend on a hidden numeric ranking of the user's team.

Evidence should be read together with the context, assumptions, and limitations that produced it. A useful diagnostic result narrows a problem and makes its basis inspectable; it does not remove the need for player judgment.

Related pages and tools

Use the Analyzer, Stress Test, and Repair tools to inspect a team. Publishing and correction standards are documented in the Editorial Policy. Questions about attribution or a source can be sent through Contact.