Methodology

The five answers

• Currently obtainable

  Every requested component can be acquired under verified rules in the selected version, and the passive slots fit.

• Legacy Pal required

  At least one component can't be created from scratch any more, but a Pal from an older version that already carries it can satisfy the build.

• Not obtainable in v1.0.3

  At least one component is proven unavailable in the selected version, with no verified legacy path.

• Invalid build setup

  The request breaks a structural rule — usually more passives than the Pal has free slots.

• Needs verification

  Our data is incomplete or our sources disagree, so we won't guess.

Breeding reachability

A component moves from parent to child. To answer "can it reach this Pal", we take every Pal that obtains the component directly, then follow verified breeding recipes outward until nothing new is reached. Reachability is computed once when a dataset is built, so a verdict is a lookup rather than a search — and identical for everyone who asks.

In v1.0.3 that graph has 299 Pals and 44850 verified parent pairs, of which 26 Pals can only be produced from two of themselves.

How a passive is resolved

Channels are checked in a fixed order: a passive fixed on the Pal, then the random passive pool, then a verified item method, then breeding. The first channel that holds decides the answer, and the channels that do not hold are what the "why" bullets say.

How an active skill is resolved

Learnset first, then an obtainable Skill Fruit, then species exclusivity, then breeding. A Skill Fruit that exists in the data but cannot be obtained never counts — the item existing and the item being available are different facts, and only the second one gives a Pal the skill.

Passive slot capacity

A Pal has 4 passive slots. A fixed passive occupies one, so a Pal with a fixed passive has fewer slots for custom ones. Capacity is checked before any graph work: a build that cannot fit is invalid regardless of whether its components are obtainable.

The legacy rule

A build is legacy only when the current version fails and an older, validated dataset says it worked. We check the older version with the same engine, and we state which version and which rule changed. If we have no older dataset for the family in question, the answer is "needs verification" — never "no".

Sources and grades

Every fact is a claim with at least one registered source and a grade from A to D. A page is only published when the claims behind its verdict are graded A or B. The grade shown next to a verdict is the worst grade among the claims it used, not the best.

See every source we use.

Validation and publishing

A dataset is checked for integrity before it can answer anything: counts, referential consistency, and coverage per family. A dataset that fails does not serve verdicts at all. Pages are published only when the answer, the reasons and the evidence all exist — the rest stay in the checker, where nothing claims to be a verified page.

Current dataset status.

Every verdict on this site is re-derived from the engine on every build, never hand-edited, and every rebuild is diffed against the previous dataset revision so a changed answer is visible rather than silent. That diff is published, not internal: see what changed in v1.0.3.

What this site does not do

• It does not calculate which species hatches from two parents.
• It does not find the shortest, cheapest, or fastest breeding route.
• It does not estimate probabilities, egg counts, IVs, or cake effects.