Okay, so here is the another article to write. And what I want to focus on this one is the risks of integrity, and especially uh, data corruption and data editing, where um, let's use the case study of Google Calendar, right? And, and I have, I know, we, we start to use creative behavior policies for Google Calendar, and one of the conclusions that we, we got, and again, just double check this, but is at the moment, although on Google Calendar you do have a delete uh, area, which is good, right? I think it's 30 days. We could do, do, just double check that and the permissions to do that. One of the things that it doesn't seem to exist is the, um, um, the creation, sorry, the, the save and the restore of edited calendar entries. And the problem with this is that if you cannot restore a calendar entry that was edited, then The problem is that you can have corruption that cannot be reverted. And that's a massive issue, right? Because if you cannot revert a change, what happens if an agent, by mistake, or part of a strategy, um, or misguided, or, or even that the user asks it to, right? Um, suddenly makes changes to 10, 20, 30, 50, 100 entries, right? And, um, and, cor and basically they are corrupted, so now we have an integrity problem. And you can't go back, right? You can't go back because there's no undo and there's no backup. So, so suddenly this becomes very, very problematic because it's a situation where now you have data corruption. And what's interesting about the calendar is that when I was basically asking the, our early users um, what was more important, and that, this is also goes for me too, right? What's more important, your email or your calendar? I actually, both me and, and, and the users I was talking to, they actually said the calendar. Because for a lot of people, uh, me included, the calendar is what controls my day, right? And, and I would follow the calendar very religiously. I would basically be focused on the calendar. Um, but I would, you know, gladly sometimes skip emails or don't look at the emails, you know. More often, it would be more of a synchronous best effort, right? Ways to, to do things, right? So, so the calendar for me was always way more important um, than the inbox. And, and now what we have here is, again, that risk. So when you start to map the behavior of this, you now have a behavior and a risk and the, and the mandates, right? That if you connect the dots, is that I only want the agent to make some changes to calendars. I don't want it to change I don't want to mass change calendars, mass edit things. And this is a good example of we can create a policy that again tells the agents to, to have very clear mandates and very clear restrictions on what you can do. And I think the calendar is a good example. But of course, databases are the same thing. Most, most customer databases and most actually environments don't have undo. They have destructive actions. You cannot revert them. You edit the message. You change something. So, uh, in some, the lead is a bit protected. Like I think what was, seems to be happening with Gmail and, and the calendar, but the editing is not protected, and that can be as damaging as as possible. And this is a good example of when we talk about the risks, right? If suddenly you realize that hold on, this thing can great can manage my calendar, but can also destroy my calendar. And then you start to say, is the risk worth it? And actually. I think what also happens is users have a very low threshold for any mistake here because any mistake is advance warning of the possibility that it can happen. So I would say that a lot of users will not nicely use uh, the calendar until a mistake happens or an attack happens, but usually it will be a mistake. And they, they go, whoa, whoa, whoa, whoa, suddenly, you know, this 10, 20 got corrupted or this thing got, got removed or something happens and they go, whoa, whoa, this is too dangerous. And basically what they're doing is they're doing a risk assessment, right? And um, and if you don't have, uh, uh, what's it called, backups, then that, that's an issue, right? And remember that, you know, even if you have daily backups, which, again, most organizations don't have, right? Um, it, it still doesn't cover everything, right? So it's, again, the ability to restore is limited. But my point is that you want to understand it, right? Like, that's part of the risk. Part of the risk of this is that, You know, and this is sort of what I think we need to calculate, is to really map the risk of an action. So if you take the risk of editing a calendar with no backup, with no undo, it's way higher than with undo. So for example, I would say today, it looks like as long as the, the risk, the, the privilege to delete an entry is also not given, the risk to delete an entry in the calendar is much lower than the risk of editing an entry because you can recover from the deletion, but you can't recover from the edit.