Partner content: Automation is strong in execution, detection is robust due to better monitoring now diagnosis needs to pinpoint why a problem happened, not only that it did
Zero-touch operations (ZTO) have become the defining ambition of modern network management. The frameworks are well established — TM Forum’s Autonomous Networks initiative, ETSI’s Zero-touch network and Service Management (ZSM) architecture, and a growing body of operator-led programmes all point in the same direction: a state where networks detect, diagnose, and recover from faults with minimal or no human involvement.
The industry has made genuine progress toward this goal. Provisioning is increasingly automated. Configuration management is policy-driven. Routine fault remediation follows pre-defined playbooks that execute without a human in the loop.
Despite this progress, operators routinely stall at the same point in their ZTO journey. Automation is strong in execution, and detection is robust thanks to expanded monitoring. The real barrier is diagnosis—pinpointing why a problem happened, not just that it did.
This is not a minor flaw—it’s a structural gap. Until it’s resolved, zero-touch operations will remain aspirational, especially during complex, high-impact events.
Where ZTO Frameworks Draw the Line
It is worth being precise about where current ZTO frameworks succeed and where they stop. The ETSI ZSM reference architecture describes a closed-loop automation framework built around the ability to collect data, analyse it, decide on an action, and execute that action — all without human involvement. This model works elegantly for a specific type of problem: faults that are well understood, frequently recurring, and resolvable through a defined remediation procedure.
Restart the process. Reroute the traffic. Scale the resource. These are actions that can be automated with confidence because the condition that triggers them is clear, the remediation is validated, and the risk of an incorrect action is bounded. The closed loop closes because every element in it is known.
The TM Forum’s Autonomous Networks framework adds a maturity dimension to this picture, defining levels of autonomy from purely manual (Level 0) through to fully self-managing (Level 5). Most operators today sit between Level 2 and Level 3 — conditional automation for specific, well-defined scenarios, with human management for anything outside those boundaries.
The ambition is to move up the scale. The challenge is that the scenarios currently outside those boundaries are not there by accident. They are the complex ones, by definition — the faults that do not fit neatly into a known pattern, the incidents that require cross-domain reasoning, the events where the cause is genuinely ambiguous.
ZTO frameworks succeed where the problem is known. They stall precisely where the problem is not.
This is the blind spot. Current ZTO frameworks assume that systems know the cause by the decision stage. For complex, ambiguous faults—the ones with the highest impact—that assumption fails.
The Closed Loop Requires a Confident Diagnosis
Consider what a genuine closed-loop automation system requires to function safely and effectively. It needs to detect that an anomaly exists. It needs to identify the scope and nature of the impact. It needs to determine the root cause with sufficient confidence to act. And it needs to select and execute an appropriate remediation. Each of these steps is necessary. None of them is sufficient alone.
Heavy investment has matured anomaly detection and improved impact assessment. But for complex issues, root cause identification remains, ironically, ZTO’s Achilles’ heel.
This matters more than it might appear. Automated remediation without accurate root cause identification is not zero-touch operations — it is automated guesswork. A system that detects a fault, cannot determine its cause with confidence, and defaults to a generic remediation procedure is not closing a loop; it’s executing the wrong action faster.
Industry frameworks explicitly acknowledge this: automated remediation systems lacking robust root-cause analysis resort to predefined playbooks that cannot adapt to cascading failures or complex interdependencies, resulting in remediation actions that address symptoms rather than causes.
In a production network, the consequences of acting on an incorrect diagnosis are well understood: unnecessary disruption to services that were not the source of the problem, configuration changes that mask rather than resolve the underlying issue, and in complex fault scenarios, cascading failures in which remediation applied to the wrong component amplifies rather than contains the original event.
These are not theoretical risks. They are the operational reality that confidence-scoring mechanisms in modern remediation frameworks are specifically designed to prevent — routing low-confidence diagnoses to human review precisely because automated action on an uncertain root cause carries known and measurable risk.
Confidence in root cause is not an optional extra in a ZTO framework. It is the prerequisite for every autonomous action that follows.
Why Assurance Has Not Kept Pace
The gap between ZTO ambition and ZTO reality in the assurance domain is not for want of effort. It shows a genuine technical challenge: complex fault diagnosis in a modern network is hard.
Network architecture has evolved faster than diagnostic tooling. The growth and scale of network domains across access, transport, core, IMS, cloud, and edge layers means that a fault in one domain may result from conditions in another, and tracing that fault requires reasoning across boundaries that most tools treat as separate.
The result is a diagnostic environment that is data-rich and insight-poor. Operations teams have more raw information at their disposal than ever before. What they commonly lack is the ability to transform that information into a confident, actionable explanation of what actually caused the problem.
This is precisely the capability gap that any serious ZTO framework must address as a core requirement. The maturity model does not progress from Level 2 to Level 4 by improving execution speed. It progresses by improving diagnostic confidence.
Diagnostic Intelligence as ZTO Infrastructure
Framing diagnostic capability as infrastructure, rather than as a feature or a tooling improvement, changes how organisations should think about investing in it. Infrastructure is not optional. It is what everything else is built on.
In the context of a ZTO programme, diagnostic intelligence infrastructure needs to do several things that are distinct from those provided by traditional assurance tooling. It needs to reason across domains, not just within them, because complex faults rarely respect the boundaries between access, core, and service layers. It needs to embed telco domain knowledge beyond just statistical pattern recognition, because the patterns that matter in a telecom network are not always statistically unusual; they are operationally significant, and that distinction requires domain understanding. And it needs to produce outputs that are actionable at the speed of automation, not reports for human review, through structured, confident diagnoses that downstream automation systems can act on without a human validation step in the middle.
This last requirement is particularly important and often underappreciated. Many diagnostic tools are designed with a human in the loop — they surface insights intended for an engineer to review and act on. In a ZTO context, this design is insufficient. If the automation system must wait for a human to validate a diagnosis before executing remediation, the loop is not closed. The human has simply moved from performing the diagnosis to approving it — a marginal improvement in efficiency, not a structural shift in operational model.
Genuine ZTO enablement requires diagnostic systems that are sufficiently confident and reliable to feed directly into automated action. That is a higher bar than most current assurance tooling is designed to meet.
The Maturity Progression, Reconsidered
Reconsidering the TM Forum maturity model through this lens produces a more useful map of what is actually required at each level of the progression.
Moving from Level 2 to Level 3 — from conditional automation to situational self-optimisation — requires the ability to handle a wider range of scenarios autonomously. The limiting factor is almost never execution capability. It is diagnostic breadth: the ability to correctly identify root cause across a wider range of fault types and network environments. Expanding that breadth requires expanding the diagnostic intelligence layer.
Moving from Level 3 to Level 4 — from situational self-optimisation to fully service-aware autonomous operations — requires something more: the ability to reason about service impact at the subscriber level, to understand not just that a network element has faulted but how that fault propagates through service layers to affect real customers. This is not a monitoring problem. It is a diagnostic intelligence problem, applied at a different layer of abstraction.
And the progression to Level 5 — fully self-managing networks — depends on something that cannot be shortcut: a sustained record of accurate, validated autonomous diagnoses and remediations that builds the confidence needed to extend autonomous action to increasingly sophisticated scenarios. That record is built by investing in diagnostic intelligence early, not later.
Building the Foundation Now
The organisations that will lead on ZTO maturity over the next five years are not necessarily the ones with the most ambitious automation roadmaps. They are the ones investing now in the diagnostic foundation that those roadmaps require.
This means treating root cause identification as a first-class engineering problem, not a human process to be supported by better dashboards. It means building systems that encode telco expertise in a durable, scalable form — so that the diagnostic capability of the best engineers in the organisation is consistently available across every incident, at every hour. And it means designing diagnostic outputs with automation consumers in mind, not just human operators.
ZTO frameworks are sound. The vision they describe is achievable. But the closed loop that they guarantee closes only when every step in the loop is genuinely reliable — including, and especially, the one that most organisations are still leaving to human judgement. Diagnostic intelligence is not the last piece of the ZTO puzzle. It is the piece that determines whether the rest of the puzzle can be assembled at all.
About the author
Daniele Di Minica is the Product Manager for Automated Troubleshooting at Anritsu Service Assurance. Daniele has over 20 years of experience in the security, intelligence and telecommunications industries and over 10 years of experience in Product Management.
He has worked in various engineering and product management roles across multiple product areas, ranging from active network testing, Event Management and correlation systems, and Contact Center Quality Monitoring to Government Security, Intelligence, and Lawful Interception.
