Dinis Cruz  0:01  
Okay, so so one of the things that I would like us to do on the the A B policy, the behaviour policy, is to a start to thinking graphs because remember that the whole point of here is that we have provenance, right? We have connections that we reuse as much as we can in the vaults, right? So, one of the things that we need to do is we need to capture the behaviours as standalone items that we can hyperlink that have, in a way, a code, right? Has a sort of a reference, an ID that we can cross-link, which eventually should also be connected to actually a Mitra, a tag tree, and should be connected to other standards and be connected to other, you know, basically you know, GDPR and stuff like that, because that's a great centre node, right? So if you look at it, thing like network access, you know. In fact, you can see that we, the behaviours. In fact, we can have behaviours which are of actions. We have control behaviours. A control is still a behaviour, right? In a way, because it's preventing the the behaviour. Well, it's a variation of it. So, so we so my idea here is to capture, for example, remote you know code execution, right? Network access, like you know changing data, acting independently, basically all those primitives that you can do, and and what this allows us to do is again to navigate the graph in multiple ways. So, if I want to say, for example, which policies impact command execution, I can see there which policies impact data deletion, data corruption, right? Which is one of the things that I feel is very important. Which is also, for example, which agents allow automation, which agents allow a large amount of actions to be made at a specific speed, because that's very important. Like, for example, you have a calendar event, but what happens if somebody puts 5,000 entries on the calendar, right? Or somebody deletes those, right? Like, what what is the actions, and then how much backups do you have, and all those properties, and again, each of these should have metrics. You know, fast, small, a lot, medium, etc. Right. So, so again, we start to build this graph because ultimately, ADP is a graph, right? If you think about, it's a connection, it's a semantic graph, right? It's a collection of nodes and edges that create the policy in itself, which is what we then create. Now, the other thing that I'm not sure we have on the policy is that is also very important is the is the multiple audiences that we should have, and I think the multiple audiences here should be the executives, and I like the idea of having the three views of CEO, CFO, and CTO, and then, but also we should have the audience of the investor, of the buyer, right, of the operator, of the engineer, right, so of the project manager, so we we can have these views, which we then filter the data, and and that's again content that goes into the into the the vault, which is why we need to start thinking about the data management and the scalability of the data management of the folks, especially as we start to have a lot of them. So that's why the more building blocks we can have here, the more we can reuse stuff, the more it becomes sort of effective on on that. Actually, one one more thing is also very important that you think in terms of projection, or I think we call prose in the website, which is the final text and the final information for the stakeholder is created from a prompt that fundamentally has all the data and all the graphs and all the evidence, so we need to share that too, right? So if you think about it, for each of those stakeholders, we also need to share exactly the prompt and the script that we've used to create that prompt, so that the the customer can replicate that. This is one of those powerful capabilities here, right? Which is actually a selling point because if somebody wants to even understand how all this is done, you know, five quid is not, or 50 quid is not a very expensive way of learning that.

Transcribed by https://otter.ai