Okay, so now the next, I think it's more section than article, and you also see if we have already covered this before, is that I want to have a section which does a bunch of different purposes. One of them, of course, is something we sell, but also it's a great way to raise awareness for, for the policies, but also a way to, in a way, help other companies. So I think there should be a win-win-win situation here, which is I would like to have a section where we make the business case for security products to be deployed based on the risk that they reduce. And in fact, we can start with risk mandate, right? And we can start with agent behavior policies because the logic here is to create the risks that exist without the tool in place and then create the risks that exist after that and see which risks got mitigated or which risks got reduced with that. So what's interesting is, and this is where you need to go and see if a lot of the work is done around the, um, what's it called, the, um, the risks that are basically the risks that are um, created and hyperlinked to senior management and the risks that are basically you know, given for acceptance at The, um, the stakeholders at the multiple altitudes. And of course, the, the point here is that there's going to be risks that we can eliminate with a particular tool. And in a way, it's okay to create risks that are directly connected to, um, to that because ultimately, we, um, that's kind of the point, right? So if you look at, for example, risk mandate, without an agent behavior policy, you have not mapped out and understood the, um, uh, what's it called, the, um, the risks and the, the reach of, um, of a particular, um, of a particular deployment, which fundamentally means that, um, We, we cannot even start by thinking about what should we focus on. So that's the advantage. But also, for example, one of our grants and one of our, um, so one of our actions is to create a policy to give to an agent. So you could say that, for example, at least with one of our policies in place, we have given instructions to the agent to uh, not do something. which A, reduces the, um, the probability that it's going to do it. For example, don't edit calendar entries more than X quantity or don't uh, make sure you have backups when you make an entry because editing a calendar entry, just example, a like Google calendar entry does not have uh, a rollback after a certain amount, so uh, after a number of edits, so um, you, you then can map that out, right? And you can say, look, at least with, even with our first basic hope-driven policy, which is you kind of hope that the agent is going to do the right thing, as we're talking nhi.skip.ai, at least it's better than not having it, right? So at least it's, it's a bit like saying, hey, don't delete the database. Be very explicit that that's not something you should do, even if you think that could be a good idea, right? Or don't, don't delete the production database, right? And, um, And so, so the, the point is that there should be a risk reduction. So, so what we want to do is we want to basically create uh, this for all sorts of security products. Like, for example, if you have a proxy solution, which is a lot of inline businesses are trying to do, or a logging solution, or a, a business layer, or an execution environment that is, has a level of security, then clearly there's risks that are reduced. So, So the way that we should be doing this, which is quite interesting, is that we should be creating, in our logic of fractal semantic graphs, we should be creating a semantic graph for a product and service and how they connect, which is also going to be interesting because some of these companies don't have that. But, um, but if we map that out, then we can then, using the semantic graph, we can then connect them with the other graphs that we have and we should be able to help to make the kind of business case for those companies. So if you look at it, the, um, the logic here, right, um, you know, the logic is that we map out, hey, what are those companies doing, then we map out what is the positive impact on risks that they're doing. And we can create risks for them, right? It's okay, right? Again, remember that you create risks all the way from the operator to the technical stakeholder to the, to the business, right? And, and basically, um, what you then have is this flow of uh, um, you have the flow of of mapping this out, right? So um, it's then uh, the mode here is that we, we should be able to make the business case for those guys and um, and that's the logic and, and it should be a win-win situation right it should be a win-win sort of use case where they basically uh, they should be happy that we have this there right and they should be happy that we are actually um, mapping this out and that we actually are um, doing this for them. And my logic is to put this on the public page and then reach out to the individuals of those companies. And, um, and then, um, well, and then, um, you know, you know, A, this helps both, so in a way this should help both the customers and the suppliers, right? And then we can have an engagement. We can have a conversation, right? So let's map this out in terms of how everything works and, um, and create the first examples. And then there's a couple of, maybe pick a couple of targets that we could use. Um, so that we, we can then start mapping out the best way to do this, right? And, um, and then maybe even do a, a quick research on the categories of this. So what kind of categories of security products exist that we could be adding here that we can make the business case for a policy. Fundamentally is the, the, the key principle here is that the policy with their tool should be, and the risks with their tool should be smaller without their tool, which ultimately is the business case for deploying a security product. And we should do this like we do with our risks, all the way from the operator, all the way to the board, or at least the senior execs, the C-level execs.