Backups are one of the hardest things to master as a judge. The main reason is that deciding whether or not to back up a game is almost always a judgement call, while the IPG tries to avoid solutions that rely on a judge’s discretion. Considering if a backup is applicable or not, and to which point you should back up, is one of the two situations in which the game state should have an effect on you decision (the other one being investigations).


The best way to improve is through real situations, but since experience can’t be taught, this exercise will highlight the dangers of a backup, and what elements should be considered before reaching a conclusion.

How to backup

Performing a backup requires two steps: deciding if a backup is really the solution we want, and actually backing up the game.

The Technical Procedures

Before delving into the theory, we’ll start by detailing the technical stuff: when are we allowed to back up, what are the backup types, and how do we back up.


The answer to the first question is simple. A quick run through the IPG reveals three infractions that allow backups:

  1. Game Play Error — Hidden Card Error

  2. Game Play Error — Game Rule Violation

  3. Tournament Error — Communication Policy Violation


While reading the “Additional Remedy” section of each of those infractions, we also find the answer to the second question - there are two kinds of backups:

  • Simple backup (HCE, GRV): undo the last action (or partial action, if the game is in the middle of something like casting or resolving a spell) that has no random elements

  • Backup (GRV, CPV): undo all actions until the point to which you’re backing up


Now that we know when we can consider a backup, and what kind of backups we’re allowed to do, we’ll learn how to actually do it. A simple backup is, unsurprisingly, simple, and doesn’t require any explanation beyond what’s covered by the regular backup (just remember: if you undo more than one action - it’s not a simple backup).


To back up the game, you need to decide the point you are backing the game to (more details about this later). Once you know where you’re going, you undo the last action, then the one before it and then the one before that, until you reach your destination. Each and every action, no matter how small or insignificant it might seem, must be reversed. Here’s a list of actions, and how you reverse them:

  • Tap a permanent: untap the permanent

  • Untap a permanent: tap the permanent

  • Shuffle the library: shuffle the library again

  • Card moved to a zone: move the card back to the original zone

  • Card was drawn: put a random card from the hand on top of the library


There might be other actions that are not listed here, but the way to reverse them should be obvious.

The Guiding Principles

The “how” is out of the way, so we can start talking about the “if” and “where to”. A simple backup takes us only one action back and it has a very limited effect on the game, so we’ll ignore it from now on (as well as HCE, which allows only simple backups).


The “where to” decision has two answers, each relevant to a different infraction:

  1. Game Rule Violation: backup until you undo the error

  2. Communication Policy Violation: backup until the point a decision was made based on erroneous information


The real problem with backups is deciding the “if”. The decision is based on the answer to the question “what would happen if I backed up the game?”, which is not always as straightforward as we’d hope.


To answer that question, we first need to understand what is a decision tree. A decision tree is a logical construct that helps us understand what players might do. The concept is a bit abstract, so it might not be intuitive at first. The “trunk” of the tree is the current game state. Players have the ability to cast spells, activate abilities and take other actions. For each option, we create a “branch”, that represents the game state as would look like if that option became a reality, and we keep going and add more branches until we map all possible outcomes.


We’ll build a tree together to try and make some sense of how it works. For this example, we’ll assume AP controls a Grizzly Bears, and NAP controls a Mogg Fanatic. The game just moved to the “Declare Attackers” step, which is our “trunk”. AP can attack with the Grizzly Bears, so we have two branches: in one AP attacks and in the other he doesn’t. If they attack, NAP can either block or not block, and also sacrifice the Mogg Fanatic.


We keep going until we end up with something that looks like this:

  • Declare Attackers

    • Attack with Grizzly Bears

      • NAP blocks

        • NAP sacrifices Mogg Fanatic

          • Targeting AP

          • Targeting Grizzly Bears

        • Combat damage destroys Mogg Fanatic

      • NAP sacrifices Mogg Fanatic

        • Targeting AP

        • Targeting Grizzly Bears

      • NAP does nothing
    • Don’t attack

      • NAP does nothing

      • NAP sacrifices Mogg Fanatic

        • Targeting AP

        • Targeting Grizzly Bears


As you can see, each branch represents an option, and branches even more as decisions create more options. After the game unfolds, we find ourselves in one of the states, and many of the options are no longer available (in this example, if NAP decides to let Mogg Fanatic deal combat damage, the option to sacrifice it is no longer available). When we back the game up, we go to older states and might make some of those options available again.


A good backup is one that avoids undoing decisions that created new branches that can greatly affect the game state. If you can manage to back up in a way that forces the players into the exact same game state, except an error that was fixed, than a backup should be applied. If, on the other hand, the game state might change, you should make a decision whether the new possible state is worth fixing the error.


Some things should be avoided as much as possible, and if a backup causes them to happen, it will almost definitely be a backup you shouldn’t do. The most prominent things to avoid are:

  • Players that gain information they shouldn’t have

  • Players with different cards in hand than they should have

  • Players gaining an advantage

  • Players taking actions with random outcomes


Back to answering the “if” question. Once you know to which point you’re backing up, you can build a decision tree, and see if it’s worth the risk. To do so, answer these questions to yourself:

  • Am I creating a decision tree that’s too big?

  • Am I making available options that greatly affect the game state?

  • Am I doing something that should be avoided?

  • Will leaving the game as is be better?


If you answered “yes” to any of these questions, the backup isn’t safe. If you answered “no” to all of them, a backup might be the right call.


Before going further, you might want to check out these:

Backing Up (IPG 1.4)

You can also read Toby Elliott’s blog or What’s Up, Docs? for more details.



This is as close as we can get you to real situations. If you feel ready, for each situation decide whether you should back up the game. If you do, to which point and what actions you back up (and how). If you decide not to, explain why.


1. Situation 1

While resolving Cathartic Reunion, AP accidentally draws 4 cards, and immediately starts casting Shock. While tapping a Mountain to pay for the Shock, NAP calls a judge. Do you back up?

2. Situation 2


AP forgets to resolve his Dark Confidant’s triggered ability, and notices it when declaring attackers. Do you back up?

3. Situation 3

During AP’s “End” step, NAP casts Lightning Bolt by tapping an Island. NAP then sacrifices an Arid Mesa to search for a Mountain. Once the Mountain enters the battlefield, NAP realises the mistake. Do you back up?

4. Situation 4

During AP’s “End” step, NAP casts Lightning Bolt by tapping Arid Mesa. NAP then untaps his permanents and draws a card. NAP wishes to sacrifice Arid Mesa, and realises the mistake. Do you back up?

5. Situation 5

AP declares attackers. NAP points to a creature that has been in a 45° angle since NAP’s “End” step, says “This one is untapped”, straightens it and declares it as a blocker. AP calls for a judge. Do you back up?

6. Situation 6

AP controls a Noosegraf Mob. During the “End” step, NAP casts Aven Reedstalker. AP removes a counter from Noosegraf Mob, and NAP untaps his permanents and draws a card. NAP casts Shock, and realises that AP didn’t put a token onto the battlefield (which was the intended target). Do you back up?

7. Situation 7

AP casts Duress. NAP discards a card, and then realises that AP used Canyon Slough to pay for it while there’s a Blood Moon on the battlefield. Do you back up?

8. Situation 8

AP casts Lightning Bolt. NAP responds by casting Mana Leak to counter the Lightning Bolt. AP pays the 3 mana, and NAP casts Cancel. NAP then realises that the Lightning Bolt was cast with no red mana. Do you back up?

9. Situation 9

AP attacks, and then notices NAP has a creature on the battlefield that was dealt lethal damage during combat on the last turn. The only actions taken since then were AP untapping and drawing a card. Do you back up?

10. Situation 10

AP controls a Vizier of Remedies and Devoted Druid. AP activates Devoted Druid’s mana ability, untaps it with its second ability, and announces that this is repeated 1,000,000,000 times. AP casts Fireball with x = 1,000, targeting NAP. At this point, NAP remembers that Devoted Druid was was the target of a Momentary Blink this turn, so it has summoning sickness. Do you back up?