The final data migration to MUIR will start at 9PM CT tomorrow, Wed, 10/29/25.
The TD/Affiliate Support Area will be shut down at that time.
TDs: If you have pending events, you need to get them submitted by 9PM CT tomorrow or you will need to start over on MUIR when it opens up on Friday or Saturday.
Is there a consolidated resource with all the changes?
will the new url just be ratings.uschess.org ?
I noticed that tournament results are being sent to the front end in this format (leading by section):
{
"id": "01K88GR9FNH4FA97PQ4TA09ZQT",
"sectionNumber": 1,
"sectionName": "OPEN",
"format": "Swiss",
"ratingSystem": "OverTheBoardDual",
"ratingRecords": [
{
"eventId": "01K88GR9FN9ZFQ6DXKAF85K0JK",
"sectionNumber": 1,
"preRating": 1686,
"postRating": 1694,
"ratingSource": "OverTheBoardRegular"
},
{
"eventId": "01K88GR9FN9ZFQ6DXKAF85K0JK",
"sectionNumber": 1,
"preRating": 1616,
"postRating": 1616,
"ratingSource": "OverTheBoardQuick"
}
],
"event": {
"id": "202401235682",
"name": "2024 OPENING MOVES SWISS",
"startDate": "2025-10-23",
"endDate": "2025-10-23",
"stateCode": "PA"
}
},
{
"id": "01K88GR9FN24KWDG2M5QAVSEDH",
"sectionNumber": 2,
"sectionName": "MINI SWISS",
"format": "Swiss",
"ratingSystem": "OverTheBoardDual",
"ratingRecords": [
{
"eventId": "01K88GR9FN9ZFQ6DXKAF85K0JK",
"sectionNumber": 2,
"preRating": 1694,
"postRating": 1694,
"ratingSource": "OverTheBoardRegular"
},
{
"eventId": "01K88GR9FN9ZFQ6DXKAF85K0JK",
"sectionNumber": 2,
"preRating": 1616,
"postRating": 1616,
"ratingSource": "OverTheBoardQuick"
}
],
"event": {
"id": "202401235682",
"name": "2024 OPENING MOVES SWISS",
"startDate": "2025-10-23",
"endDate": "2025-10-23",
"stateCode": "PA"
}
},
Does this mean that if I play in two sections of a tournament there will be two line items in my tournament history with the same event name? And what is the best way to understand the rating progression in a predictable way? In other words, will section 2 always be rated first then section 1 builds off 2?
Thank you!
That would be consistent with the way the current system works. We have always considered sections to be independent of each other, though under a common event name and ID. The only impact the games in a section has on other sections in that event or other events is to possibly be a playerâs most recent event from the perspective of that other section.
To be honest, I donât know what the URL for MUIR will be yet. It wouldnât surprise me if it is the one you found, though. Reverse engineering the new site isnât high on my priority list.
I think the way data is being loaded has nothing to do with the order in which events will be rerated, once MUIR starts rerating events next week. As far as I know, the order in which events are rerated will continue to be:
Section Ending Date
Section Beginning Date
Event ID (Based on the latest section ending date of any section in the event)
Section Number (the order in which the TD puts the sections.)
FWIW, there were lengthy discussions between myself and the Ratings Committee back in 2004 when I was trying to convince them that rerating would work. I had to demonstrate to several PhDs on that committee that I had an ordering scheme that was probably about as good as one could get, and had the primary virtue of being unambiguous. Given a new event, there is only one place in the chain of events for any player where it fits. (This is, as I understand it, similar to how block chains work.)
I had similar discussions with the FIDE technical people when I went to the Turin Olympiad in 2006, because they hadnât figured out how to rerate FIDE events. I donât know if those led to FIDE changing their procedures or not.
While this has to be a fairly pathological case, does that mean you go down to event ID as the final tiebreaker after exhausting the start date / end date options, in the case of multiple events with the same start and end date for a given player?
Yes, though it happens surprisingly more often than you might think. If multiple sections of an event have the same starting and ending dates, then the section number determines the order in which they are rated.
in the normal course of rating events, does this mean that in the following scenarioâŚ
Event A
Section End Date: 10/20/2025
Submitted: 10/21/2025
Pre 2000; Post 2025
And then a new event B is submitted
Section End Date 10/10/2025
Submitted 10/23/2025
My pre and post rating from Event A will change ? or will B work off the post rating from A?
Assuming the section beginning dates are the same, the 12 digit Event ID will determine which section is rated first.
Now, hereâs the fun part. The event ID has 3 parts:
YYYYMMDD for the first 8 digits
NNN a serial from 000 to 999 for the next 3 digits
0, 1, 2, or 3 for the 12th digit.
The final digit tells us in what era the ratings were generated.
0 means the event came from before I started working on the ratings system.
Events ending in 1 were from the first version of TD/A (most people donât even realize it changed in 2012, that had to do with when we started enforcing time control parameters, before then we were pretty much on the honor system for the TD telling us which rating system(s) an event should be rated under, now the time control unambiguously determines what rating system(s) it should be rated under.
Events ending in 2 are ones generated since 2012. (Some of them do go back before 2012 because of late submissions.)
I believe I recommended to Leago that they use a 3 as the last digit of events generated on their system once we turn MUIR on in a few days.
There are a handful of events from 2004-2006 that have a 3-9 as the last digit, these were events that were given event IDs manually to deal with some special situations back then.
OK, now letâs talk about digits 9, 10 and 11. This is a 3 digit serial that flips back to 000 when it gets to 999. Each new event that is generated, including test events that never get submitted for rating, gets a new ID from the event ending date and the next number in the sequence 000-999. So that means it wraps around from 999 back to 000 every few weeks, so the event that is started on first will usually get a lower 3 digits than one ending on the same date but started later on. But, once every few weeks that wraps back around to 000 again so is is possible that the later-submitted event gets the lower ID. We could have assigned a random order for events with the same beginning and ending dates, but we needed a unique key for the event anyway, so we just used the event ID.
If we had ever had 999 events ending on the same date, that system would have broken. Fortunately, that never happened. As it turns out, the event ending date with the most number of events is a tie between November 16, 2024 and November 11, 2023, both with 159 events.
oh but in my example, the section end dates were different.
To make it a bit more to the point and see if I understand. Letâs assume two events in which Player A participates in each section (all sections are reg time control):
Event A
Section Open
Section Extra Games
Submitted: Oct 15th 25
Event B
Section Open
Section Extra Games
Submitted: Oct 18th 25 (second submission)
Would it be your expectation that the ratings would calc as follows:
In this case, you couldnât have an event Post rating that would make sense right?
In your case, when event B was submitted it would initially be rated using some event that ended prior to event B, letâs call it C. But then event A would need to be rerated to get the ratings flowing from event C to event B to event A, because B is now the most recent event as far as event A is concerned, even though it was submitted later.
As I described the situation to Leago, when rating event B you have two choices as to what event to consider the âmost recentâ one, and both of them could be considered wrong from a certain point of view. But rerating fixes that by putting the events into chronological order based on the ending date, beginning date, ID and section number.
Yes, I hadnât considered the âExtra Rated Gamesâ section when I was thinking about it earlier.
Although over 90% of events are now rated within 2 days of when they end, we still do see some events straggle in late, usually because something kept them from being submitted faster.
There have been a few instances of a TD dying before submitting the report from their last event, for example. When the family and local chess community is grieving, somehow getting that event submitted just isnât the highest priority.
ahhh ok got it. So you rate the event in its entirety rather than splitting up sections. That is what i was missing. Thanks!
Will the complete TD/A portion of the Dasboard be shut down or just the tournament submission portion of the the TD/A area?
No, we order the event based on the section ending date, not the event ending date, that only factors into setting the 12 digit event ID.
So if you have someone who plays in a saturday tournament, a sunday tournament and a saturday-sunday tournament all on the same weekend, the saturday only event is rated first, then the saturday-sunday event then the sunday-only event.
Itâs confusing, it took me several hours on a white board to make sure I was getting it right.
Initially the whole thing will be shut down, because what Iâll do is set the âTD/A is downâ flag Nearly all the TD/A programs check that flag before starting anything.
The reason weâre doing it that way is so that if, for some unforeseen reason, we canât turn MUIR on, we just reset that flag and TD/A is back up again.
We could selectively bring parts of TD/A back up individually after that, but Iâm not sure what the path will be to get to those tools.
The MSA pages will be unaffected, because theyâre on a different server, one that is essentially read-only. The final MSA rerate is still getting posted, we can only update about 3000 events an hour and there are tens of thousands of events affected by a rerate.
Thankfully, that will be in the past under MUIR, because it isnât relying on a secondary database that has to be kept in sync.
Before we started keeping ratings in floating point in between events, only about 4% of events were affected by a rerate, but since 2014 over 90% of events can be affected by a rerate. So the whole structure was due for an upgrade anyway.
Once the cut over to MUIR happens, will the member records as shown here:
Be as current as the ones shown here:
In other words, if someone walks into our club and signs up for US Chess, will I see them nearly instantly in both searches?
The plan as I understand it is to replace the pulldown on new.uschess.org to search for members with a link to the MUIR system, so there should be just one search point, which is what we had before July 2020.
That being said, it should be receiving âpushâ updates from CIVI-CRM, so it should be pretty current.
TD/A has been shut down, the final data migration will start shortly.
As of our regularly scheduled Thursday afternoon internal Zoom call, everything is, as NASA used to say, âgreen and goâ for launch. We donât have an ETA for the launch yet, probably Friday afternoon or Saturday morning.
Bryan Tillis is working on getting the video of Mondayâs MUIR demo posted on YouTube, as soon as he sends me the link, weâll post it here on the Forums and on new.uschess.org and you can see the final walk-through he did on Monday, where he did one event from DBF files and another entering all the data online.
When MUIR goes live, the plan will be to block access to the beta site, to minimize confusion over having both a live and non-live system available. (To re-emphasize a point, you CANNOT submit an event for rating on the beta site, it is for testing ONLY!)
We may set up a sandbox or testing site next week for people who want to practice in an environment where thereâs no possibility of affecting any live data. But weâd need to figure out just what that system needs to be to be useful to people. If people donât need it and wonât use it, thereâs no reason to pay for its existence. (No cloud-hosted sites are free, ya know.)