David Warnock, Blue Planet (00:09):
Okay, so I'm going to give you 10 minutes on what is probably the least glamorous problem in AI-native networking, and that's the data beneath it. Just give you a few seconds to take that in. What's wrong with this picture? So I came across this on a social media platform maybe two years ago now, and the poster is asking ChatGPT to draw a map of the UK and giving it some parameters to deal with. But what it came out with is something quite surprising, really. If you can see anything wrong with this, just shout out.

(00:49):
I think that the first thing is that the south of England is actually the north of France. Now, historically, that may have been true. In the 13th and 14th century, Britain and France, or England and France, were at war with each other and parts of France were in the UK, but it's not the answer that we're looking for today, right? Also, you might notice that there are five Bristols, one of which is in northern France, and it's called Brisel, which interestingly enough, is how people from Bristol pronounce Bristol. Now, this is image generation, right? It's not AI, but imagine this is a map of your network. Okay.

(01:31):
So the failure mode is identical. But the model wasn't lying. It was reasoning confidently over data that had no reliable structure underneath it. And this is exactly what happens when an agent reasons over unreconciled data. So the hard part of AI-native operations is not the AI, it's the data underneath it. Now, Gartner has proposed that 60% of AI projects will be abandoned in 2026 unsupported by AI-ready data, not because the models failed, but because the data was never ready for them.

(02:13):
So what does ready actually mean in this context? Well, to me it means four things. So first of all, we need to have trusted data so that we can make reliable decisions. Does the record in the network and the inventory management system match what's actually in the network? Because if our inventory management system thinks that a card is in slot three, but it was moved 18 months ago, then every downstream decision made from there is going to be wrong.

(02:42):
The data needs to be connected, so can you correlate across multiple domains? When you get, for instance, a fibre break, it generates hundreds of alarms sometimes, and those alarms will be across multiple domains. How do you correlate that into a single root cause alarm, so that you're raising a single ticket rather than many tickets?

(02:58):
We need to have operational context. So relationships are important, not just records. What service does this port carry? In the case of our fibre break, there could be hundreds of services running over that particular piece of fibre. So which of the services are impacted, but also there could be SLAs associated with those services, and so it could be costing us money. And so understanding that operational context is very important to us.

(03:26):
Lifecycle awareness is also very important. A service can be in a pre-production state, it can be live, it could also be undergoing change management, and that's important for the network operations to know that. So understanding the part of the lifecycle that, that service is in, is also very important to operations. So clean data is not a data quality project. It is these four properties held in continuity.

(03:58):
And I'm going to talk about ontology for a minute here. Everything I just described assumes that the machine knows what the data means. That is what an ontology does, not a schema. A schema tells you the shape of the field. An ontology tells you what that thing is, how it behaves, and what actions are possible against it. So just to break that down for a minute, what the data means, well, it's a common vocabulary across multiple domains and across multiple vendors, such that if we just say what a circuit or a port or an interface is, that means the same thing across all vendors and all domains. Secondly, how the network behaves, the real-time relationships and the dependencies in the network, and also what actions are possible so that an agent can make a sensible decision and can reason about the options, not just report a state. So this is the difference between an AI that describes your network and an AI that you would let touch your network.

(05:02):
And this is a journey. And I would say that probably every organisation that's represented in this room is in a different stage of that journey. But there are important milestones along the way of the journey that I think need to be considered. So the first thing you need to do is you need to be able to see the live network. You need to then understand that network across multiple domains and to give a unified view of the network such that you have a topology. You need to be able to trust the state of the data. So it needs to be live, it needs to be federated. And from there, you can actually start to think about the context of the data, and you can work within the lifecycle of that context. That then allows you to share intelligence. But to move to full autonomy, you need to be able to do closed-loop automation.

(05:55):
Now, we have a saying in Blue Planet, "You can't AI what you can't see." Which is true, and I've got my own personal saying, and that is, "How can we do closed loop if you don't know what the root cause of the problem is?"

(06:07):
So legacy operations improve when a human looks, but autonomous operations improve when the data is shared, and that is the whole difference.

(06:22):
So one slide on how we do this at Blue Planet, and then I'll get back to the problem. We have an inventory management system, an orchestrator, and an assurance system, and now we've just released a change in configuration management system. Underlying this is a common data layer. It's all installed in a native AI platform, Kubernetes-based. On top of that is a common data layer, and on top of that is an AI layer, so the agents can actually share the data across those applications and make context-sensitive decisions on how to remediate various problems.

(07:00):
Back to the problem now. Now, I've been working in OSS for more than 35 years now, I think. I think the grey hair is probably a testament to that. And I used to work in a NOC, back in the mid-'90s, and we had multiple assurance systems for different domains. So we had a mobile assurance system, we had an IP assurance system. We also had lots of EMSs for the different transport domains. And when we got something like a fibre break, we would get alarms on all of those systems, and we had to go between them and figure out what the root cause of the problem was. We'd have to do it manually because we didn't understand the context of the whole network. Our inventory management system was a whole bunch of spreadsheets. Our orchestration system was people sitting at keyboards doing command line configuration.

(07:51):
And that's developed now. So I think what we need to do from there is to actually converge those systems so that you've got a single inventory management system, a single orchestrator, and a single assurance system across multiple domains. That needs to be supported by a common data layer, and underneath that, a context fabric, so that we have a full end-to-end topology of the network. But to move to fully autonomous systems, we need to think about capabilities such as digital twin. We need to think about context graphs. We need to understand what the context of the business is of anything that we do to the network. And that allows AI to make context and business-level decisions. And we're moving away from the time that I spent in the NOC, manually doing correlations and things like that, to actually a supervisory mode for operations.

(08:48):
Interestingly enough, our customers don't want to go to level five at the moment. They want to have a human in the loop, and I think there's various legislation in different countries and different regions that doesn't allow to not have a human in the loop.

(09:04):
So automating a silo makes the silo faster at being wrong. But business-aware operations means that the decision knows the customer, the service, and the commitment beyond the port. So I'm not trying to sell you anything here, but I would ask you to take these questions back to your AI programme, and I'll just concentrate on a few of them. First of all, can your AI explain where its data came from? Is your data connected or just collected? And do we clean the data once through a data cleansing programme, or do we do that in every silo forever? Because if you cannot answer these questions, your AI programme is going to produce a very confident map of a country that doesn't exist. Thank you.

Guy Daniels, TelecomTV (09:56):
Thank you. Thank you, David.