Why assurance needs open ‘data + domain’ federation and what packet core teaches the wider network

Modern networks generate more signals and more dependencies. A single service-impacting problem often requires telemetry, topology/inventory, configuration, traffic behavior, and service context from different systems – often from different suppliers. Teams still spend large amounts of time manually assembling that context, repeating work across shifts and suppliers, and making decisions when the picture is incomplete.

This shows up clearly in packet core, but the same pattern appears wherever failures propagate across domains.

Why packet core is a practical starting point

Packet core failures can affect service quality quickly. That makes it a strong place to validate an approach under real operational constraints. In TM Forum’s Multi-agent intelligence for packet core operations Catalyst championed by Jio, Telia, Telus and Vodafone Three and demonstrated recently at DTW Ignite, packet core is the anchor domain. However, the aim is a repeatable workflow, not a one-off proof.

The workflow to prove is concrete: Group signals into a situation, add domain-specific explanation, reason about cause and impact, recommend or execute next steps under policy, and record outcomes for the next event.

Root cause and impact use the same cross-domain evidence

In real networks, “What broke?” and “Who is affected?” usually need the same inputs: dependencies across domains, time-aligned signals and service/topology context. If operators do not build that picture once and reuse it, they tend to rebuild it twice – once for root-cause discussions and again for impact and prioritisation.

When operators talk about progressing toward higher autonomous network maturity, the practical meaning is often the same idea expressed two ways: shorten the path from detection to a defensible decision and keep that path repeatable as services, vendors and domains multiply. That is hard to do if “cause work” and “impact work” live in different tools, teams and partial graphs.

Unified assurance is a useful mental model here as one operational thread that can carry enough cross-domain context for triage, correlation and decision support.

Cross-domain health and probable cause capture the same intent: operators need health (including customer- and service-visible symptoms) and probable cause (what best explains the situation) to be assessed in a way that respects boundaries between domains and recognizes that what happens in one domain may correlate with events in other domains.

Multi-vendor environments need two layers

Most CSP networks use more than one vendor. A single-vendor AIOps product can work well for data that stays inside that vendor’s scope. It is weaker when the incident cuts across boundaries.

A workable pattern is:

1. A neutral integration layer that can ingest and correlate operational data from multiple sources (telemetry, topology/inventory, alarms and related context), so operators are not rebuilding the same integrations for every new tool and every new incident type.
2. Domain expertise that stays authoritative for each domain (for example, packet core), because the detailed failure modes and engineering constraints remain vendor- and domain-specific.

The Catalyst program matches this split: Deep packet-core knowledge stays where it belongs, while the program still needs a coherent operational picture built from multiple inputs.

What ‘agentic operations’ should mean in practice

In practice, agentic assistance should be described in operational terms that can be verified during incidents and post-incident reviews.

• Situation-centric work – group-related signals are needed so triage starts from a shared situation object, not from hundreds of unrelated alarms.
• Domain expertise in the loop – packet-core (and other domain) specialists remain the authority for what is physically plausible, vendor-specific and safe; automation augments them with correlation and drafts, not overrides their judgment on high-risk decisions.
• Evidence-backed recommendations – every recommended next step should carry what was correlated, from which sources, and why so that teams can review, challenge and approve with traceability.
• Explicit governance – policy gates, approvals and audit records are part of the default design for anything that can change service state or customer traffic.
• Recorded outcomes – store decisions, actions and post-change results so repeat incidents do not restart from zero, and so domain experts can correct the system without losing the thread across shifts and suppliers.

Interoperability decides whether this scales

If the industry wants autonomy to scale beyond pilots, interoperability cannot remain bespoke glue forever. A practical industry trajectory is:

• Near term – standardized integration patterns and open interfaces for exchanging enriched situations, topology context and decision artifacts.
• Longer term – agent-to-agent collaboration models that allow specialist agents to participate without rebuilding entire chains and under shared governance and measurement discipline.

That trajectory is bigger than any single Catalyst, but a Catalyst is a good place to pressure-test the assumptions with real workflows and real constraints.

In conclusion

If the goal is faster and safer restoration in real CSP environments, the practical question is whether investment goes mainly into more isolated domain tools, or into an open composition layer that works across vendors and preserves domain-owned technical truth.

Packet core is a good place to prove the workflow. The next step is to reuse the same pattern across additional domains without losing governance.