And there was something we did so that certain teams couldn't just dismiss an assert pop-up and continue with their work if it was directly related to them?

Yeah, so that's exactly right. I feel like an AI when I say that now: you're absolutely right. But yeah, we changed the way the assert dialogues work. So asserts, for those who don't know, is like when I'm a programmer and I'm asserting in an area of the code that this value must be set to 1. That means that if the value comes in and it's not 1, then we'll have an error that will show up. That's the assert error. And typically, you need to action asserts or something else is going to go wrong. And so historically, the assert dialogue was just a global thing. And then we still have those get assigned to dev teams. So they are classified by code owners and by dev team. And so you can know if it's an audio assert or if it's a programming assert or whatever, which is great. But we allowed people to ignore those either completely or just skip them. And on the other hand, when you're actually testing the game or playing the game, you get these asserts. So you want to ignore them because you're doing something else. You're not in assert fixing mode. We've changed the relationship towards asserts inside the company so that now you can ignore errors for any other team but yours. So if you get an assert error, you need to fix it. That's it. Because the thing that we were seeing in the company was basically teams going like, oh, when are these... I'm going to pick on audio. Sorry, Graham and team, I'm not picking on you guys, it's just random. But like, when are the audio guys going to fix their asserts, right? When, as you know, the reality is we all have our own asserts to fix. And so we changed that relationship as well.

We even found some, I'm not going to blame anybody, but we've got analytics inside the company, so we know who's turning the asserts off, right? So we found some shit.