A proxy matchup gauntlet in MTG does not need to be eight complete decks glaring at you from eight deck boxes. The useful part is the repeatable field: saved opponent lists, clearly labeled versions, consistent test conditions and notes tied to a specific question. Keep one or two opponents assembled, store the remaining lists as snapshots, and rebuild only what the next test batch requires.
“Matchup gauntlet” is not an official Magic rules term. In deck-testing practice, it generally means a curated slate of opposing archetypes or decklists. Human games and software simulations are also different evidence categories; do not pour both into one win-rate bucket and call it science.
Start with a question, not a pile of decks
A gauntlet should answer something narrower than “Is my deck good?” Pick one question that can produce observable evidence. Does the revised mana base keep more opening hands? Can the deck function through early interaction? Does a new protection package preserve the commander long enough to matter? Does the Cube control deck have enough time to stabilize against the current aggressive list?
Write that question at the top of the batch record. Then decide what must remain stable while you investigate it. Changing the candidate list, opponent list, mulligan rule and pilot assignments at once may produce entertaining games, but it will not isolate which change mattered.
Build opponent roles before choosing lists
Do not begin by copying every deck that recently beat you. Define the pressures your deck must face, then select one saved list for each relevant role. Depending on the format and your test question, those roles might include a fast proactive deck, a disruption-heavy deck, a resilient value deck and a deck that attacks from an unusual angle.
Each role needs an exact list snapshot. “The usual control deck” is not a snapshot. Save the full list with a short identifier such as Control-A-v1.2, the date saved and a one-line note describing the revision. Version control works because it preserves states that can be compared or restored later; the same principle applies even if your entire system is a folder of deck exports and a spreadsheet rather than Git. Git’s explanation of version control describes the underlying snapshot-and-restore idea.
For a first gauntlet, three or four opponents are enough. More decks create more assembly work, more pilot variation and fewer games against each saved configuration. Expand only when the existing field fails to represent a pressure that matters to the test question.
Keep the library permanent, not every physical deck
Your permanent gauntlet can be a digital list library plus a smaller physical kit. Keep the candidate deck assembled, prepare the opponent needed for the next session and retain reusable lands, tokens and clearly labeled test cards in sorted packets. After the batch, return those pieces to the kit and assemble the next opponent from its saved manifest.
Label every temporary card for fast sorting, especially when authentic cards and playtest cards share a deck. The goal is transparent use, not passing an unofficial card off as authentic. Wizards distinguishes playtest cards from counterfeits on that basis and limits sanctioned-event proxies to narrow judge-issued replacements; this workflow is for agreed testing, not evading event policy. Wizards’ proxy policy explanation For mixed decks, use a consistent proxy-labeling system that remains readable without creating face-down tells.
If frequently reused existing MTG printings justify a dedicated order, proxyfoundry.com is one available route for playtest cards. Keep volatile experimental slots easy to replace, because a beautiful card that becomes obsolete after two games is still obsolete.
Before running a batch, sleeve the assembled deck consistently and perform a quick marked-card audit. A warped card, different sleeve or obvious thickness change can contaminate decisions involving mulligans, tutors or known top cards.
Give every change a new version
Freeze the candidate list for the duration of a batch. If you replace two lands after game three, game four belongs to a new version. Do not combine the records and report them as though one unchanged deck played the entire set. The same rule applies when an opponent list changes.
A simple naming system is enough:
- Candidate-v0.3: exact deck export plus date.
- Opponent-Control-v1.2: exact list used during the batch.
- Batch-07: test question, candidate version and opponent versions.
- Change note: what changed from the previous candidate version and why.
- Rollback note: which earlier snapshot to restore if the revision fails.
Record the format, rules date and ban-list check date as part of the batch context. Wizards maintains current rules and banned or restricted information on its official Magic rules page. That small timestamp prevents an old gauntlet file from quietly pretending it reflects current conditions.
Log observations, not reconstructed statistics
Write one raw row immediately after each game. Memory becomes suspiciously cinematic once the pizza arrives. A compact log is more valuable than a detailed form nobody completes.
| Field | What to record | Why it matters |
|---|---|---|
| Batch and question | Batch ID and the single hypothesis being tested | Keeps conclusions tied to the original purpose |
| Versions | Exact candidate and opponent identifiers | Prevents different lists from being combined |
| Conditions | Format, pilots, mulligans, seating or play/draw | Captures factors that can change the result |
| Outcome | Result plus end turn or approximate duration | Preserves the basic game record |
| Deciding event | The observed event relevant to the question | Provides context beyond a win or loss |
| Comments | Attributed player reactions or rules exceptions | Separates feedback from measured outcomes |
Useful observations are statements the log can support: how many recorded games used a particular opponent version, whether a tracked card was drawn or cast before the relevant event, or which mulligans were actually recorded. Participant comments can identify problems worth testing next, but “Alex said the deck felt oppressive” is feedback, not proof of a power ranking.
Do not invent missing game data after the session. If nobody recorded opening hands, you do not have a mulligan-rate result. If end turns were not logged, you do not have an average game length. An unlogged estimate does not become evidence because a spreadsheet formats it to two decimal places.
Adjust the method for multiplayer Commander
A Commander gauntlet tests a pod, not merely Deck A against Deck B. Record player count, seating, commanders, pilots, mulligans and any agreed rules changes. Winner and elimination order may matter, but so can the turn cycle, the board state relevant to the hypothesis and whether table politics redirected pressure. A binary win-loss column throws away much of that context.
Set expectations before the session. The Commander Rules Committee describes Rule Zero as a group-consensus discussion, so establish proxy use, intended power band and whether the session is exploratory or competitive before shuffling. The official Commander FAQ provides the relevant Rule Zero context. If the pod needs a quick script, use a 30-second proxy conversation rather than delivering a pregame dissertation.
End each batch with a limited conclusion
Close the batch before revising anything. State which saved lists were used, which conditions remained stable and what the recorded games suggest within that scope. Then choose one action: keep the candidate version, make a named revision, repeat the same batch or add an opponent that exposes a missing pressure.
A curated gauntlet measures the opponents, pilots and conditions you actually included. It does not establish an overall metagame ranking, and a small batch cannot prove that one card solved a matchup. The honest payoff is smaller and more useful: a reproducible snapshot, a defensible next change and the ability to roll back when your brilliant revision turns out to be three medium cards wearing a trench coat.