The NKG: Knowing Where Everything Connects
The biggest practical challenge in network operations is not that data doesn't exist – it is that the same network element has a different identity in every system. The router in your inventory system has a different ID from the same router in your ticketing system, your performance monitor, and your fault management system. When something goes wrong, operators spend hours just figuring out that these different IDs all refer to the same physical device.
The NKG solves this by serving as a central, queryable graph of all entities and their relationships. It models the network as a connected hierarchy:
- Physical Topology: Fixed infrastructure - routers, servers, access edge devices - and how they connect to each other
- Logical Topology: The containerized network functions (CNFs) and virtualized functions (VNFs) running on top of that infrastructure
- Service Layer: How those logical functions map to actual services - VoLTE, network slices, broadband - that depend on the underlying infrastructure
- Business Layer: Which customers and segments consume those services, under what SLAs
The critical chain this creates: Physical Device → CNF/VNF → Service → Customer. An agent can traverse this chain in either direction - from a failing component up to affected customers, or from a customer complaint back down to root cause infrastructure.
The TKG: Knowing When Everything Changed
If the NKG is the map, the TKG is the timeline. It records every event that changes the network's state - not just that something happened, but exactly when, on exactly which element.
Every planned change (a Method of Procedure, or MOP) is logged as a timestamped relationship: (MOP-ID-X, Alters, CNF-A, Time t₁). Every anomalous event is similarly logged: (Router-B, Experiences, Latency Spike, Time t₂). This granularity transforms the TKG from a simple event log into a causal reasoning engine - one that can answer "did t₁ cause t₂?" rather than just "did t₁ happen before t₂?"
The TKG also continuously tracks performance and fault data over time, giving agents the historical baseline needed to identify genuine drift rather than normal variation.
Bridging the Gap: Linked Identifiers in Action
The real power of this dual-graph system emerges when the two views work together through what we call the Linked_To relationship - a mechanism for automated identity resolution across systems.
Here is what this looks like in practice: A Change Management Agent receives a notification that CI-ID-xxxx has been updated in the ticketing system. In isolation, this is just an abstract ticket ID - meaningless to the network view. The agent traverses the NKG to map this ID to the live network element: CI-ID-xxxx → Linked_To → CNF-A-Core-Instance → Identified_As → NE-ID-yyyy.
In one traversal, the system now knows:
- From the NKG: which physical device was touched, which logical services depend on it, and which customers are in the blast radius
- From the TKG: the precise timestamp of the change and every subsequent event that occurred on dependent elements
This is the moment where correlation becomes causality - and where autonomous agents can act with confidence rather than guesswork
Conclusion: Intelligence Through Explainability
The NKG and TKG together don't just make the system smarter - they make it explainable. Every agent decision is anchored in a verifiable graph path and a timestamped ledger. When an agent concludes that a midnight change caused a service degradation, it can show its work: here is the dependency path in the NKG, here is the timeline of events in the TKG, here is why this is causality and not coincidence.
This explainability is what keeps human experts firmly in control. Engineers are not asked to trust a black box - they're presented with structured, traceable evidence that they can verify, challenge, or approve. In the next part, we'll see exactly how this plays out in a real change management scenario.
In this part, we have covered:
- Why the Knowledge Graph has two logical views - spatial and temporal - and why that separation matters
- How the NKG maps the full chain from physical infrastructure to customer impact
- How the TKG creates a causal ledger of every state-changing event
- How linked identifiers bridge the identity gap across siloed systems
Looking Ahead: Part 3 – The Dual Engine in Action
In Part 3, we will bring the NKG and TKG to life through a complete change management scenario: a planned software upgrade during a midnight maintenance window that leads to unexpected service degradation. We will also walk through exactly how agents trace the causal chain - from the moment of change to the moment of impact - and how the system moves from diagnosis to autonomous remediation.
