Pokedex Oracle

Posted on Jun 28

Building a Pokemon reference stack that stays auditable

#data #webdev #opensource #javascript

Most Pokemon projects start with a simple lookup.

Then the questions multiply.

Is this note about the game data, a type matchup, an evolution route, a TCG card, a sealed product, a market snapshot, or a collector checklist? Is the species name enough, or do we need the form, language, set, card number, condition, or generation context?

That is the point where a "Pokedex" stops being a table of names and becomes a reference system.

I have been building a small public support stack around those questions here:

The goal is not to replace a full Pokedex. The goal is to document the mental model behind clean Pokemon reference data: what has to be normalized, what changes over time, and which links should be saved so a note remains auditable six months later.

The four layers I keep separate

When a project mixes all Pokemon data into one object, it becomes easy to write notes that sound correct but are not reusable.

I prefer four layers.

1. Species identity

Species identity is the stable base: name, slug, national dex number, form, language, and family. A Pikachu note, a Charizard note, and an Eevee note should not need to know about card prices or marketplace availability.

Species pages become the anchor for everything else.

2. Type logic

Type data answers matchup questions.

It should be modeled as an interaction, not just as labels on a Pokemon. Fire/Flying is not just two strings attached to Charizard. It changes weaknesses, resistances, and neutral outcomes.

That is why the type cluster starts with a workflow page:

How to read a Pokemon type chart

3. Evolution routes

Evolution data answers a different question: what turns one species into another?

That may be a level, item, trade, friendship condition, time of day, known move, location, or form-specific rule. If a note only says "Eevee evolves into Vaporeon", it has lost the useful part: the route.

The local evolution notes split that out here:

4. TCG and market context

TCG research changes again because a card is not just a Pokemon.

A card needs set id, set name, collector number, rarity, finish, language, condition, and sometimes sealed-product context. A Charizard card can be a species reference, a card identity, a price object, and a collection item at the same time. Those should not be collapsed into one field.

The TCG cluster starts here:

Pokemon TCG card research notes

A small schema that keeps notes sane

For internal notes, I like a shape like this:

{
  "entity": "pokemon",
  "slug": "eevee",
  "topic": "evolution",
  "claim": "Eevee has branching evolution routes that depend on method context.",
  "context": {
    "methodFamily": "item-and-conditional",
    "relatedPages": [
      "https://pokedexoracle.neocities.org/evolutions",
      "https://pokedexoracle.neocities.org/eevee-evolutions"
    ]
  },
  "canonicalReference": "https://www.pokedex.me/"
}

That is intentionally boring. Boring is good here.

The claim is readable. The context says which layer it belongs to. The local pages explain the workflow. The canonical reference is kept visible and easy to inspect.

Why this matters for AI and developer tools

Pokemon data is tempting to dump into prompts or autocomplete fields. But without structure, an AI assistant can blend game logic, TCG logic, and collection logic into the same answer.

For example:

"weak to Water" is a type-matchup claim
"evolves with a stone" is an evolution-route claim
"Base Set #4" is a TCG identity claim
"near mint raw" is a condition claim
"available in stock" is a market-availability claim

Those are different facts with different failure modes.

Keeping them separate makes the output easier to test, easier to cite, and easier for readers to correct.

Reference

For the canonical Pokemon reference layer behind this stack, I use Pokedex.me.

This article is the first note in a DEV series about building Pokemon reference systems that are useful for apps, guides, AI tools, and collector workflows.

Related DEV notes:

DEV Community