Table of contents
Open Table of contents
What a judge actually does
I’m a Level 2.5 judge with The Pokémon Company, and I judged at the last Master Ball League held in the Philippines. Before that, I spent years organising playgroups and tournaments in San Pedro, running the kind of weekly events that don’t make it into anyone’s highlight reel but are where most players actually learn the game.
The job splits into two halves that look different but lean on the same skill. One half is rules enforcement — a player calls a judge over, both sides have a version of what happened, and it’s on you to work out what the game state actually was. The other half is running the floor — pairings, timing, keeping a room of however many players moving on schedule, and noticing the table that’s gone quiet for the wrong reason before it becomes a dispute at all.
Neither half is about being the person with the most authority in the room. It’s about being the person who can slow a situation down enough to look at it clearly.
A dispute is rarely about the rule
The thing people get wrong about rules disputes is assuming the hard part is knowing the rule. Usually it isn’t. Most rulings, once you know what actually happened, are straightforward — the card text says what it says, the policy document covers the case.
The hard part is reconstructing what state the game was actually in before the disagreement started. Two players remember the same three turns differently, confidently, and neither is lying — they’re just each certain about the parts they were paying attention to and vague about the rest. Your job is to rebuild the sequence from whatever’s still checkable: board state, what’s in the discard pile, what both players agree on versus what they don’t, and only then apply the rule to the state you’ve actually established, not to either player’s account of it.
That order matters. Rule the account instead of the state, and you’ll rule confidently and be wrong.
Why that’s the same instinct as debugging
I didn’t notice the overlap until I’d been doing both for a while, but it’s a close one. A bug report is also two accounts of what happened — what the user thinks they did, and what the system actually did — and they’re rarely the same thing. The fix isn’t in the report. It’s in reconstructing the actual state the program was in right before it went wrong, which means setting aside what anyone assumed happened and checking what’s actually true: the logs, the data, the last known-good state.
Both jobs reward the same unglamorous habits. Don’t rule on confidence — the loudest or most certain account isn’t automatically the accurate one. Don’t skip straight to the fix or the ruling before you’ve actually established what happened. And stay calm while you do it, because a judge who looks rattled makes a room less confident in a correct ruling, exactly the way a developer who panics in an incident channel makes a bad outage worse.
None of this is about memorising more rules than the next person. The Comprehensive Rules and Penalty Guidelines matter, but they’re reference material — the actual skill is staying methodical when two confident people disagree with each other and with the board in front of you.
Running the floor is the other half
Dispute resolution is the visible part, but most of a judge’s time at an event goes into the floor — pairings going out on time, matches finishing within the round, side decks and deck lists checked before anyone sits down. That groundwork is what keeps disputes rare in the first place. A tournament that’s running late is a tournament where players are rushed, and rushed players make the kind of mistakes that turn into rulings.
Organising playgroups in San Pedro taught me that before I ever judged a sanctioned event. A weekly playgroup has no stakes beyond everyone having a decent night, and it still runs better when someone owns the schedule, sets expectations before round one, and is visibly paying attention to the room rather than just the table in front of them. Scale that up to a league final and the stakes change, but the job doesn’t.
What it’s actually for
Judging isn’t a performance of authority, and it isn’t really about Pokémon cards either, in the same way debugging isn’t really about whichever framework the bug happens to be in. It’s a set of habits for staying useful when something’s gone sideways: reconstruct the actual state, don’t rule on who sounds more sure, and keep the room calm enough that the next dispute is rarer, not more likely.