I'm hoping someone can link me to / explain in detail how cascading re-pairs work, in both theory and practice.

When someone comes up after pairings have been posted and says they have the wrong point total, and we discover their previous round results were entered incorrectly, how do we make the decision to leave the pairings as they are vs to re-pair?

If it is determined we should re-pair the match instead of leaving it as is (so we aren't giving the player an advantage by having them play a worse opponent), how do we decide who each player should be playing against?

How much of all this is handled in the program?

Edited Brook Gardner-Durbin (Nov. 15, 2018 03:16:57 PM)

There used to be many great articles in this Blog, including one detailing
such process: http://www.mtgscorekeeper.com
But I can't access the website right now, not sure what's the problem. I
tried to google a cached version of the website, with no success
If someone can help with this, it was a great resource

Like many things in scorekeeping, there is no official documentation on cascade repairs. Their methodology and execution varies between scorekeepers; (and HJs) my process alone has gone through two mentionable changes in the last three months.

So, I'll at least give my personal answers here, but even here, I'll leave the caveat that nothing here is official and these answers are general guidelines, and not even “this is how I'll handle this situation”, because like in judging, the specific circumstance dictates a lot of the choices. Also note that some of the philosophy here applies to all fixes SKs make - an SK could hold up the entire tournament while a match or drop is fixed, but we do all these partial fixes specifically to avoid the time loss of a full re-pair or round delay.

Practically-speaking, a one-minute delay by the SK is scrutinized more than a five-minute delay due to a HJ ruling or investigation.

When someone comes up after pairings have been posted and says they have the wrong point total, and we discover their previous round results were entered incorrectly, how do we make the decision to leave the pairings as they are vs to re-pair?

The decision tree realistically boils down to:
- The rank of the players in question
- The current round time

Both of these generally boil down to “which option affects tournament integrity the least”, between leaving things as-is, a full fix, and a partial fix.

Note that “and we discover their previous round results were entered incorrectly” is mostly-irrelevant to this situation - these days, SK errors and player errors are generally resolved identically. (with some SKs, the priority is getting the players playing, and getting players moved/playing is a much higher priority than discovering the “why”)

If it is determined we should re-pair the match instead of leaving it as is (so we aren't giving the player an advantage by having them play a worse opponent), how do we decide who each player should be playing against?

If we're breaking pairings, (for both fixing results and no-show re-entries) in general, there are three guidelines I go by:
- If there's a pairing that, by breaking it, will result in fewer pairdowns or a lower difference in points between pairdowns, that's the priority to break.
- If choosing between several tables, choose as randomly as possible.
- Don't let the perfect be the enemy of the good. The longer you take to do anything, the greater effect you have on the matches you're changing.

For “my last round is backwards” errors, the fix is almost always to just swap the two players. This is the most convenient option, and the matches affected are the ones that are also affected by the error result.

For “no show re-entries”, I try to focus my efforts right at the borders of the whole-match point totals. i.e. if I'm adding a 6-pointer, I'll be breaking tables right at the 6-5 point threshold, then again at the 3-2 threshold. Again, I can be perfect with infinite time, but debating = time, and time = stopping players that are 5 minutes into Game 1.

How much of all this is handled in the program?

There's no automation to the process outside of how you would actually break and re-pair the tables. There's no fast method to verify that pairings are not repeats, so it's a balance between perfect pairings and fast work.

My process to do this these days is to have a piece of paper handy, with all the tables I'm breaking. For example, with a cascade re-pair, I'm either with pairings-by-table (WER) or on the match screen (WLTR) pretty much telling a line of judges what to do, writing down only numbers at the same time. Once all the judges are out fixing things, I'll have a list of numbers written down like:

18
131
352
542
620

Which is short-hand for “the right player at these tables is being moved down to the next table, and the last table player gets a bye”. (which is what I told judges, just in the manner that gets the tables fixed quickly)

Note: One of my recent changes comes after an issue in GPNJ, where I was informed that there's a potential for issue here where one table gets held up, and causes the player at Table 18 to see what his opponent at Table 131 is playing. So now I call tables out backwards to try to help with this.

Thank you, Jordan!

When you say “between leaving things as-is, a full fix, and a partial fix” – a full fix would be doing a full re-pair for every player in the event?

I've seen this happen very rarely, even at small local events. When might this be a good option to choose over leaving as is/repairing just a few matches?

Edited Brook Gardner-Durbin (Nov. 15, 2018 06:22:34 PM)

When you say “between leaving things as-is, a full fix, and a partial fix” – a full fix would be doing a full re-pair for every player in the event?

Correct - a full fix would be repairing the entire round to have all players receive pairings determined by the software.

When might this be a good option to choose over leaving as is/repairing just a few matches?

I think the most common time this may be chosen is when a player notifies the SK of an error as the overwhelming majority are still milling around, trying to find their seats for the round. It's generally only at local stores, when you don't have software like online pairings, either. It's only really feasible if players haven't started playing for the round (partial fixes like a cascading repair usually occur as a round starts and the first few minutes into it), and even if players have all found their seats, you're adding an additional delay for them to all pack up, look at pairings again, and find their seats.

Jordan may have some additional use cases for full repairs, but you are absolutely right that they are rarely used. Delaying 3 matches (6 players) or so up to 5 minutes can save you a lot more time than delaying every match and every player in your event only 2 minutes (at least from a customer service perspective, not necessarily an end of round perspective).

Originally posted by Federico Verdini:

There used to be many great articles in this blog, including one detailing such process: http://www.mtgscorekeeper.com
But I can't access the website right now, not sure what's the problem. I tried to google a cached version of the website, with no success
If someone can help with this, it was a great resource

It can still be accessed here.

Thanks everyone!

Thanks a lot Isaac!
Here are the articles I was referring to:

http://mtgscorekeeper.blogspot.com/2016/01/wer-editing-matches-aka-how-to-not.html

http://mtgscorekeeper.blogspot.com/2016/01/wer-editing-matches-2-cascades.html

Hope it helps