Tweaks

PokeScan: I Built an Analytics Platform for Pokémon Cards

Why a toy-priced market with real market structure is the ideal place to stress-test AI analytics architecture.

Everything described in this series was built, run, and broken on personal equipment, on personal time, against publicly available Pokémon TCG market data. No employer systems, data, tooling, or internal processes are involved, and nothing here draws on them. The opinions are mine and are not offered on behalf of any employer.

I built an analytics platform for Pokémon cards.

This is not a joke, and this series is not really about Pokémon. It’s about the architecture patterns you need when you let a large language model participate in analytics as a compute layer, not just a chat layer. I needed a place to test those patterns where the measurements would be real and the mistakes would be cheap. Pokémon cards turned out to be nearly perfect for the job.

why this market

Strip away the artwork and the nostalgia and the Pokémon TCG is a functioning alternative asset market. Tens of thousands of tradeable instruments across two hundred plus sets. Deep daily price history. Supply dynamics driven by print runs and set lifecycles. A grading layer that stratifies nominally identical cards into certified quality tiers, with a public, cumulative census of how many exist at each tier. Liquidity tiers, from cards that trade hourly to cards that trade twice a year. Sentiment shocks when a video game gets announced.

Every hard problem in market analytics shows up here in miniature. Entity resolution (which “Charizard” do you mean, out of several hundred printings). Data quality (printing variants that silently corrupt a price series). Stale data detection. Screening across the full universe. Technical signals. Backtesting.

And critically: the whole thing is mine. Public data, my pipeline, my server, my mistakes. When I publish a number in this series, it came off a system I own end to end, and I can show you the wiring.

[LOAD-BEARING] A market with toy prices and real structure is the ideal substrate for a reference implementation. You get production-shaped problems without production-shaped blast radius.

what PokeScan actually is

PokeScan is an MCP server. You connect it to an AI client and you talk to the market in plain English. “Show me WOTC-era holos with sub-1% gem rates trading under $50 raw.” “How has Crown Zenith’s set index moved against 151 at the same lifecycle point?” The model resolves the entities, calls the right tools, and the server does the math.

Under the hood it’s a Python server, a data pipeline, three databases, and about two dozen tools. PokeScan is a reference implementation, not a blueprint for anyone else’s system. I use it to isolate the engineering transitions that show up when frontier-model capability meets operational constraints: cost, latency, semantics, observability, repeatability, and control. None of the plumbing is the interesting part. The interesting part is what running it taught me, because every lesson generalizes to any system where an LLM sits in the analytics path.

what the series is about

One pattern runs through everything that follows: capability sits on a specialization gradient, from a generic fallback that can answer anything expensively to a purpose-built tool that answers one thing cheaply. The useful question is never which point to pick. It’s how workloads move along that gradient over time. I call the mechanic the promotion pipeline, and it turns out to apply as much to how you render a chart as to how you run a query.

From there the series works outward: what it costs to let a model do arithmetic it shouldn’t, why one class of question doesn’t get expensive on the generic path so much as fall off a cliff, how to divide decisions between the server and the model, and what data has to carry with it for a model to reason over it without quietly getting it wrong.

Next up is the promotion pipeline itself. Everything else in the series hangs off it, so it goes first.

the deal

Every one of these posts is rooted in something I built or broke on this system. Real token counts, real latency numbers, real data corruption I had to diagnose at 11pm. Where a number is measured, I’ll say so. Where it’s extrapolated, I’ll say that too. A number you can’t trace isn’t evidence, it’s decoration.

phil-karpowich.com/writing/introducing-pokescan