Change Management in Telecom Networks: From the Method of Procedure to the Digital Twin

At 00:17 on 18 September 2025, a contractor applied a lock to a firewall gateway at an exchange in Adelaide as the first step of a planned upgrade. The method of procedure selected for the job dated from 2022 and did not include the step that diverts emergency-call traffic before the gateway is locked; the six previous upgrades in the same programme had not applied a lock at all. Ordinary calls re-routed themselves. Emergency calls did not. Over the following thirteen hours, roughly 455 of 605 attempts to reach the Australian emergency number from four states and territories failed, the alerts raised in the first half hour were assumed to be artefacts of the upgrade, and the independent review commissioned afterwards counted around ten separate mistakes, summarized as “processes not followed, incorrect procedures selected, inadequate checks, controls avoided, and alerts given insufficient attention” (Schott review, December 2025). The wrong procedure had passed peer review by three engineers. In July 2026 the regulator took the operator to the Federal Court alleging 1,005 contraventions of its emergency-call obligations (ACMA, July 2026).

Nineteen months earlier, at 02:42 Central Time on 22 February 2024, an employee of the largest mobile operator in the United States placed a new network element into production during a routine maintenance window. Its configuration did not conform to the operator’s own design and installation procedures, which required peer review; the review had not taken place, and a second employee loaded the element without confirming that it had. Three minutes later the network entered a protective mode that disconnected every device from voice and 5G data. More than 125 million devices were affected, more than 92 million voice calls were blocked, more than 25,000 attempts to reach 911 failed, and full restoration took over twelve hours because the rollback — completed in about two hours — triggered a mass re-registration that overwhelmed the registration systems. The regulator’s findings listed the causes without euphemism: “a configuration error, a lack of adherence to internal procedures, a lack of peer review, a failure to adequately test after installation, inadequate laboratory testing, insufficient safeguards and controls to ensure approval of changes affecting the core network, a lack of controls to mitigate the effects of the outage once it began” (FCC Public Safety and Homeland Security Bureau, July 2024).

Neither of these was a failure in the sense that operators design for. No fibre was cut, no power was lost, no attacker was involved, no component wore out. Both were planned changes, executed by competent people inside processes that existed on paper, and both became national outages because the process that was supposed to govern the change — review it, test it, stage it, contain it, verify it, reverse it — did not govern it. The same is true of the Canadian outage of July 2022, the two Japanese outages of 2021 and 2022, the Australian outage of November 2023, the French emergency-number outage of June 2021, and of the cloud and security-software outages of 2024 and 2025 that disconnected airlines, hospitals and, in several cases, the telecom operators’ own customers. The pattern is consistent enough to state as a rule, and Google’s reliability engineers stated it a decade ago: roughly 70% of outages are due to changes in a live system (Google SRE, “Introduction”).

The thesis of this article is that change governance is the highest-return reliability control an operator owns, that it is systematically under-engineered relative to redundancy and monitoring, and that it can now be industrialized end to end — intake, impact, collisions, procedure, rollback, authorization, pre-checks, staged execution, service verification and closure — with automation and AI. But only in that order, only on top of an inventory that can say what depends on what, and only with AI beside the critical path rather than on it. What follows is the frameworks that govern change, a redesign of the process itself around governed state transitions rather than tickets, the whole lifecycle stage by stage, the role of the inventory, the automation of every stage, the agents and the digital twin, and what operators and hyperscalers have actually shown.

1. The change is the outage: what the post-mortems actually say

The post-mortems of the last five years form a dataset, and reading them together is more instructive than reading any one of them. They were written by regulators, parliamentary committees, independent reviewers and the companies’ own engineering organizations, in four jurisdictions and two industries, about networks built by different vendors on different architectures. The mechanisms differ — a routing filter removed, a firewall locked, a configuration file corrupted, a feature deployed without a flag — and the controls that failed are the same seven, in different combinations, every time.

The telecom cases, with the official findings

Date, operator	The change	What went wrong	Scale	Official finding on the process
Oct 2021, NTT Docomo (Japan)	Migration of IoT subscriber registration data to new servers; errors led to a rollback	The rollback forced mass re-registration; each failed registration triggered retries; signalling storm spilled into 4G/5G and 3G voice and data	Up to 29 hours	Ministry classified it a “serious accident” and ordered “thorough preparation for switchover work” (MIC, Nov 2021)
Jun 2021, Orange (France)	Configuration modification on all six call servers linking IP and legacy voice, to raise capacity	A routine procedure executed in an unusual order, on all servers simultaneously, triggered a latent software bug; servers rebooted in a loop for seven hours	Over 10,000 emergency calls not delivered; deaths linked by the authorities	Government report found no supervision able to detect the problem before customer reports and hours of delay in alerting authorities; a legal continuity obligation for emergency calls followed (French Senate, 2021)
Jul 2022, Rogers (Canada)	Phase 6 of a seven-phase IP core upgrade; a routing policy filter was removed from distribution routers	The full Internet routing table flooded the core routers beyond their capacity; the management network rode on the same core, so engineers lost access	12 million+ subscribers, ~15 hours, 911 and the national debit network down	“The change management process … failed to flag the erroneous configuration change”; the risk algorithm had automatically downgraded phase 6 from High to Low after earlier phases succeeded; no overload protection on core routers (Xona Partners for the CRTC, 2024)
Jul 2022, KDDI (Japan)	Router replacement on the nationwide transport network during maintenance	The new router was misconfigured and discarded VoLTE location-registration signalling; terminals retried en masse and congested the voice exchanges and the subscriber database	61 hours 25 minutes; ~22.8 million voice users; ¥7.3 billion in compensation	KDDI attributed the escalation to “insufficient work preparation and inadequate consideration of congestion control”; ministry issued administrative guidance (KDDI, July 2022; MIC, Aug 2022)
Jun 2023, BT (UK)	Configuration error in a file on the media server of the emergency-call platform	Call-handler systems restarted whenever a call arrived; the first switch to disaster recovery failed through human error because the instructions were “poorly documented” and staff “unfamiliar with the process”	~14,000 failed 999 attempts over 10.5 hours	Fined £17.5 million; insufficient warning systems, no adequate procedure to assess severity, disaster-recovery platform with insufficient capacity (Ofcom, July 2024)
Nov 2023, Optus (Australia)	Routine software upgrade on the parent group’s international peering exchange produced a routing-information change propagated to Optus	About 90 provider-edge routers received updates exceeding pre-set safety thresholds and self-isolated; many needed physical resets	~10.2 million customers, 12 to 14 hours, 2,145 failed emergency calls	Senate committee found communications “manifestly inadequate”; CEO resigned; A$12 million penalty for emergency-call breaches (Senate report, Sept 2024; ACMA)
Feb 2024, AT&T (USA)	New network element placed into production during night maintenance to expand capacity	Misconfigured element, loaded without the required peer review; downstream elements propagated the error and the network entered protection mode three minutes later	125 million+ devices, 92 million+ calls blocked, 25,000+ failed 911 attempts, 12+ hours	No peer review, inadequate lab testing, no post-installation test, insufficient controls to prevent loading unapproved changes (FCC, July 2024)
Sep 2025, Optus (Australia)	Planned firewall upgrade at a regional exchange, executed by a contractor	A 2022 procedure without the emergency-traffic diversion step was selected and passed peer review; the gateway was locked; emergency calls did not re-route; early alerts were treated as false alarms; national monitoring hid the regional failure	~455 failed emergency calls over ~13 hours; deaths linked by the independent review	“Processes not followed, incorrect procedures selected, inadequate checks, controls avoided, and alerts given insufficient attention”; a pre-change meeting lacked the required core-network engineers; 21 recommendations (Schott review, Dec 2025)

The 2025 and 2026 outages in the United Kingdom and the United States follow the same shape, even where the root cause has not been published. A UK-wide voice outage in June 2025 was attributed by the operator to “an exceptional spike in network traffic triggered by a third-party software configuration change”, and a software issue at a second UK operator a month later blocked calls to other networks and to 999; both are under regulatory investigation (Ofcom, Dec 2025). Two multi-hour outages at a large US mobile operator, in September 2024 and January 2026, were described only as “a software issue”; the second affected more than 1.5 million subscribers for around ten hours and no root cause has been published. The absence of a published cause is itself informative: the operators that publish are the ones whose regulators made them.

The hyperscaler and software cases: the same controls, at global blast radius

The digital-infrastructure outages of 2021 to 2025 matter to telecom operators for two reasons: their services now depend on these platforms, and their post-mortems are the most detailed in existence. In October 2021 a command issued during routine maintenance to assess backbone capacity took down every connection in Meta’s backbone; the audit tool designed to stop such commands had a bug, DNS withdrew its routes by design, and recovery took more than six hours and physical access to data centres (Meta Engineering, Oct 2021). In July 2024 a content update pushed to every Windows host running a security sensor crashed about 8.5 million of them; the vendor’s root-cause analysis found a validator with a logic error, a missing bounds check, test coverage that used wildcards and therefore never exercised the failing path, and the absence of staged deployment — the remediation was canary rings and customer control over update timing (CrowdStrike RCA, Aug 2024).

The 2025 cloud outages are, if anything, more instructive, because each involved a sophisticated change-safety system that was bypassed or blind. On 12 June 2025 a quota-policy feature added to Google’s Service Control “without appropriate error handling nor was it feature flag protected” was triggered by a policy change containing blank fields that replicated globally within seconds, crash-looping the service in every region for about three hours (Google Cloud incident report, June 2025). On 29 October 2025 “an inadvertent tenant configuration change” at Microsoft’s global edge produced incompatible metadata that exposed a latent data-plane bug; because the failure was asynchronous, the rollout’s health checks passed, the bad configuration propagated through the staged rollout and overwrote the “last known good” snapshot, and recovery took eight and a half hours; the post-incident review attributed the escape to “a gap in our pre-production validation, since not all features are validated across different control plane build versions” (Azure post-incident review, Oct 2025). On 18 November 2025 a change to database access permissions at Cloudflare caused a query to return duplicate rows, doubling a feature file beyond a hard-coded limit and crashing the core proxy in what the company called its worst outage since 2019 (Cloudflare, Nov 2025).

The lesson from the cloud cases is not that staged rollout failed. It is that staged rollout only protects against failures it can observe. A health check that measures the wrong thing, a canary that cannot see an asynchronous failure, a global replication path that bypasses the stages, a “last known good” that can be overwritten by the bad change: each of these converts a staging system into a propagation system. The cloud operators’ remediations are a design brief for anyone building change automation — feature flags off by default, synchronous validation before propagation, immutable rollback points, a kill switch that does not depend on the failing component — and section 7 returns to them.

Seven controls that failed, across every case

Read side by side, the investigations identify the same seven missing or defeated controls, and the list is the specification for the rest of this article:

Control that failed	Cases
Independent review or approval gate absent or ineffective	AT&T (no peer review); Rogers (audit failed to flag the change); Optus 2025 (wrong procedure passed three-engineer review); CrowdStrike (validator defect)
No representative testing before or after deployment	AT&T (inadequate lab testing, no post-install test); Rogers; Azure (cross-version validation gap); Google (no flag, no error handling); CrowdStrike (wildcard-only tests)
No staged rollout; global blast radius by design	CrowdStrike; Cloudflare 2019 and 2025; Google (global replication in seconds); Azure (rollback point overwritten); Orange (all six servers at once); Meta
Risk misclassified or automatically downgraded	Rogers (algorithm downgraded phase 6 from High to Low); Optus 2025 (incorrect risk classification)
No fail-safe or overload protection to contain the change	Rogers (no router overload protection); AT&T (downstream elements lacked controls); Optus 2023 (routers self-isolated); KDDI and Docomo (signalling storms)
Rollback or recovery not prepared or not tested	AT&T (re-registration storm after rollback); Docomo (rollback caused the storm); KDDI; BT (disaster-recovery switch failed on poor documentation)
Monitoring blind to the change’s effect; management path on the changed network	Optus 2025 (emergency calls excluded from regional monitoring; alerts dismissed); Orange (no supervision detected it); Rogers (management network on the failed core)

The statistics behind the anecdotes

The cases are not outliers; the incident statistics of the whole industry say the same thing with less drama. The European telecom security incident reporting aggregated by ENISA for 2024 counted 188 significant incidents across the member states. Faulty software changes and updates were only 14% of them by count, but they caused more lost user-hours than any other technical cause — around 524 million, against 331 million for cable cuts — and within the human-error category they were the single largest cause, averaging more than 26 million user-hours per incident (ENISA, Telecom Security Incidents 2024). The 2022 edition was starker: faulty software changes were 12% of incidents and roughly 77% of all user-hours lost that year (ENISA, 2022 incidents). A change-induced incident is not more frequent than a cable cut. It is an order of magnitude larger when it happens. The UK regulator’s own count for October 2022 to October 2024 points the same way: of 2,732 resilience incidents reported to it, 2,045 were system failures including faulty network changes, and “changes to networks were the main driver of incidents with the highest customer impacts” (Ofcom Security Report, 2024).

The data-centre and enterprise view agrees. In the Uptime Institute’s 2026 outage analysis, 92% of respondents said human error contributed to their most recent impactful outage; “failure to follow procedures” was the top human-error cause at 59%; “configuration or change management failure” was the leading cause of network-related outages at 41%; 57% said the outage cost more than US$100,000 and one in five more than US$1 million; and 87% judged that it could have been avoided with better management, processes or configuration (Uptime Institute, Annual Outage Analysis 2026). Telecom operators accounted for 39 of the 122 publicly reported major outages the institute tracked in 2025, against a long-run average of 29. The software-delivery research adds the benchmark that an operator should hold itself to: in the 2024 DORA study, the elite performers’ change failure rate was 5% and the lowest performers’ 40%, and in the 2023 edition the lowest group stood at 64% (DORA, Accelerate State of DevOps 2024). A network change programme that does not know its own number cannot know which group it belongs to.

What the cases add to the statistics is the shape of the consequences, which in telecom are not confined to lost revenue. Rogers paid C$150 million in customer credits, committed C$261 million to physically separating its wireless and wireline cores, and announced a C$10 billion reliability programme; its chief technology officer was replaced within two weeks (CRTC report). Optus lost its chief executive after the 2023 outage and faces a potential exposure of about A$251 million in the proceedings over the 2025 one. BT was fined £17.5 million; KDDI returned ¥7.3 billion to subscribers; France changed its law. The regulators’ responses — resilience guidance in the United Kingdom, emergency-call rules in Australia, reporting obligations in the United States, the implementing rules of the European cybersecurity directive — now describe change control explicitly, and section 2 turns to what those frameworks actually require.

2. The frameworks: what each one governs, and the gap they all leave open

Change management is one of the most thoroughly standardized processes in IT and telecom, and that is precisely why the outages of section 1 are so instructive: every operator involved had adopted at least one of the frameworks. The frameworks are necessary — they define the vocabulary, the roles, the change types, the authorization model and, increasingly, the legal duty — and they are not sufficient, because they govern around the technical procedure rather than inside it. Four families matter, each from a different tradition, and understanding what each one actually covers is the fastest way to see where an operator’s own process has to supply what the frameworks do not.

Service management: ITIL 4 and its cousins govern authority, types and schedule

ITIL is the framework most operators mean when they say “change management”, and its current edition deliberately changed both the name and the model. ITIL 4 calls the practice change enablement and defines its purpose as maximizing the number of successful changes by ensuring that risks are properly assessed, authorizing changes to proceed and managing a change schedule (ITIL 4 Practitioner: Change Enablement, PeopleCert). Three design decisions in it matter for a network operator. The first is the typology: standard changes are low-risk, well-understood and pre-authorized through an approved change model; normal changes are assessed and authorized case by case; emergency changes are expedited with the assessment compressed and the review done afterwards. The second is the change authority: ITIL 4 explicitly moves away from the single change advisory board of earlier editions toward authority assigned to the people closest to the risk, with a board reserved for the changes that need it; the practice guide’s own words are that such boards “often become bottlenecks for the organization’s value streams”, and the high-velocity guidance built on it holds that peer-reviewed changes within a team can achieve the same level of risk optimization as a board (AWS, “Change enablement in ITIL 4”). The third is the change schedule as a shared, queryable artefact used to plan, to avoid collisions and to communicate — the calendar as a safety system rather than a diary.

The cousins of ITIL add auditability and the language of control. ISO/IEC 20000-1, the certifiable service-management standard, requires that changes be classified, assessed for risk and impact, approved, scheduled, tested and reversible, and that the organization review their effectiveness (ISO/IEC 20000-1:2018). COBIT’s “Managed IT Changes” objective frames the same requirements as governance controls with defined evidence (ISACA, COBIT 2019). The NIST security-control catalogue, which many operators now adopt through their security programmes, contains a configuration-change-control family that requires changes to be documented, tested, validated and approved before implementation, with an explicit impact analysis and the ability to retain previous configurations for rollback (NIST SP 800-53 Rev. 5, CM-3 and CM-4). What none of these specifies is how to assess impact on a network, how to test a routing change, or what a tested rollback looks like for a core network function. They define that it must be done, who signs for it, and what the auditor will ask for.

Telecom architecture: TM Forum and ETSI govern the process model, the data and the autonomy

The telecom-specific frameworks do not replace ITIL; they supply what ITIL assumes exists — a model of the network, its services and its customers, and interfaces between the systems that hold them. TM Forum’s business process framework places change within the resource and service management processes of an operator, and its Open Digital Architecture defines the components and the open APIs through which a change tool, an inventory and an assurance platform exchange information. Three of those APIs are the ones a change programme touches directly: the change management API, which standardizes how a change request, its approvals, its impact and its schedule are represented and exchanged (TMF655 Change Management API); the resource inventory API, which exposes what exists (TMF639 Resource Inventory API); and the service inventory API, which exposes what the resources are for (TMF638 Service Inventory API). An operator that assembles its change capability from several suppliers’ tools needs these contracts more than any individual feature, because the impact analysis of section 4 is a query across all three. The change management API’s single resource, the change request, carries impact, risk, a mitigation plan, planned and actual times and related trouble and problem tickets, and moves through twelve states that include a post-implementation review and a fallback execution — the lifecycle of section 4 in machine-readable form (TMF655 v4.0.0); Bell Canada exposes a production profile of it to its partners, built around a catalogue of pre-agreed change types (Bell Canada, Change Management API specification, 2023).

TM Forum’s autonomous networks framework gives change management something the other frameworks lack: a measurable scale for how much of it the system does. The six levels, from L0 (manual) to L5 (fully autonomous), are evaluated per operational scenario rather than per network, with the methodology defining which of the perception, analysis, decision and execution tasks the system performs and which a person performs at each level (TM Forum IG1252). Applied to change, that produces a planning language that section 7 uses: a change type at L2 is executed by the system and decided by people; at L3 the system also assesses and decides within the scenario, with people handling exceptions; at L4 the system handles the scenario including exceptions under human intent. The accompanying reference architecture describes the closed-loop, intent-driven, knowledge-guided structure within which those levels are reached (TM Forum IG1251). The Forum’s Level 4 industry blueprint lists “network change” among its eleven high-value scenarios and “success rate of major changes” among the key effectiveness indicators, and notes that operators’ self-assessments cluster between Level 2 and Level 3 despite public Level-4 pledges (TM Forum, Autonomous Networks Level 4 industry blueprint, Nov 2024).

ETSI’s zero-touch network and service management group supplies the architecture for the automation itself. Its reference architecture defines management domains, an end-to-end service management domain, and the integration fabric through which they coordinate, with closed loops — monitoring, analysis, decision, execution — as the basic automation construct across domains and layers (ETSI ZSM). Its closed-loop automation specifications define how loops are governed, how they interact, and how conflicts between loops are managed, which is exactly the problem a change loop and an assurance loop face when both can act on the same element (ETSI GS ZSM 009-1, Closed-Loop Automation: Enablers). Its 2024 digital-twin specification defines the network digital twin as a virtual replica of the network used for what-if modelling — the standards definition of rung five in section 10 (ETSI GS ZSM 018). Its 2026 work is the standards track that the agentic architecture of section 9 will be measured against: a study on agents in autonomous networks that uses a network change agent as one of its examples and states that supervised autonomous agents “require operator verification, adjustment, or explicit approval before critical actions” (ETSI GR ZSM 020, Jan 2026), a study of the path from automation to autonomy (ETSI GR ZSM 021, May 2026), and an architectural specification for agent-based management whose principles include operation authorization — agents execute only authorized operations — and explainability and auditability (ETSI GS ZSM 022, Oct 2026). ITU-T’s autonomous-networks architecture adds the knowledge base and the experimentation sandbox as first-class components — a standards-level acknowledgement that validation before action is part of the architecture, not an add-on (ITU-T Y.3061). 3GPP’s levels-of-autonomy specification adds a rule that every change programme should adopt verbatim: human-reviewed decisions have the highest authority at every level if there is any conflict (3GPP TS 28.100).

Engineering practice: SRE, DORA and GitOps govern how a change actually reaches production

The engineering frameworks come from the companies whose outages are in section 1 and whose practices are in section 11, and they are the only ones that say anything concrete about execution. Google’s site reliability engineering doctrine states the problem and the response in one paragraph: because most outages come from changes to a live system, the best practices are progressive rollouts, quick and accurate detection of problems, and safe rollback when problems arise, all of them automated (Google SRE). The companion workbook’s treatment of canarying — exposing a small, representative fraction of the system to a change, comparing its behaviour against a control, and promoting or reverting on evidence — is the most precise published description of what section 5 calls staged execution with stop rules, and its rule that “deployments should be performed by computers, not humans” is the shortest statement of section 7 (Google SRE Workbook, “Canarying Releases”). The same workbook observes that “configuration changes tend to dominate outage root causes over time in a system” and prescribes gradual deployment, rollback and, at minimum, automatic rollback or the ability to stop progress if a change leads to loss of operator control (SRE Workbook, “Configuration Specifics”; “Configuration Design”).

The DORA research programme supplies the metrics, and they transfer to network change with almost no modification. Change failure rate, deployment frequency, lead time for changes and time to restore service are the key measures of software-delivery performance, benchmarked annually across thousands of organizations (DORA metrics); the 2024 study placed elite performers at a 5% change failure rate with recovery in under an hour, and the lowest performers at 40% with recovery taking a week to a month (DORA, Accelerate State of DevOps 2024). The research’s central finding — that speed and stability are not a trade-off, and that organizations which deploy more often also fail less often, because small, frequent, well-tested changes are safer than large, rare ones — is the argument against the freeze-and-batch instinct that governs many network maintenance calendars; its capability research adds that heavyweight, external approval does not reduce failure rates, while peer review and automated testing do (DORA, “Streamlining change approval”). GitOps and continuous-delivery practice add the mechanics: procedures and configurations under version control, reviewed as code, tested in a pipeline, deployed declaratively and reverted by restoring a previous version. Section 7 applies this directly to the method of procedure.

Regulation: when change control becomes a legal duty

The fourth family is the newest, and it was written by the regulators who investigated the outages. In the United Kingdom, Ofcom’s resilience guidance for communications providers, issued in September 2024 under the security duties of the Communications Act, expects “a robust change management process and set of tools” whose main objective is “to control and coordinate network and service changes with minimum impact to service availability”, together with the review, testing and management of change for the detection and prevention of misconfiguration (Ofcom, Network and Service Resilience Guidance, 2024); the regulator’s own security report for 2022 to 2024 found that of 2,732 resilience incidents, 2,045 were system failures including faulty network changes, and that “changes to networks were the main driver of incidents with the highest customer impacts” (Ofcom Security Report, Oct 2022 to Oct 2024). The telecoms security code of practice under the 2021 security legislation is more specific still: “operational changes shall only be made according to a formal change process except under emergency or outage situations”; emergency access outside change windows must raise alerts and be audited afterwards; changes that could affect security must be notified to those monitoring the network; equipment configurations must be “regularly and automatically collected and audited to detect unexpected changes”; security testing must follow any significant change; and changes should be made through administrative systems such as the OSS rather than through direct privileged access (UK Telecommunications Security Code of Practice, 2022, measure M11.01 and related measures). In the European Union, the NIS2 directive requires essential entities, telecom operators included, to secure the acquisition, development and maintenance of their systems (Directive (EU) 2022/2555, Article 21), and the Commission’s implementing regulation for digital infrastructure — cloud, data-centre, content-delivery, DNS and managed service providers, which most large telecom groups also are — spells out what that means for change: documented change-management procedures covering releases, modifications, emergency changes and configuration changes, tested and assessed for impact before implementation according to the risk, with every emergency deviation documented together with the reason the procedure could not be followed (Commission Implementing Regulation (EU) 2024/2690, Annex, point 6.4). In the United States, the regulator’s report on the February 2024 outage measured the operator against the industry’s own best practice to “verify complex configuration changes before committing them and test after the change” and referred the matter for enforcement (FCC, July 2024). In Australia, the review of the 2023 outage produced eighteen recommendations, all accepted (Australian Government, review of the 8 November 2023 outage, 2024), a 2025 law created an emergency-call custodian with the power to direct testing during upgrades and maintenance, and the 2026 proceedings allege more than a thousand contraventions of the emergency-call rules. In Canada, the regulator’s report on the 2022 outage was followed by commitments on change control, testing and management-network separation that the regulator states have been implemented, and by a 2025 decision requiring notification of major outages within two hours and a report within thirty days (Telecom Decision CRTC 2025-225).

The common thread across jurisdictions is that the regulators are no longer asking whether an operator has a change process. They are asking for evidence of specific controls, after the fact, with the outage as the test case. Peer review that actually happened; testing that was representative; a staged deployment that could have been halted; a rollback that worked within a known time; monitoring that would have seen the effect; and a management path that survived the change. Those are the controls of section 1, and they are the content of sections 4 and 5.

The gap they all share

Laid side by side, the four families cover the governance, the data, the execution and the duty — and leave the same three things to the operator. None of them specifies the method of procedure: the ordered, verifiable, reversible set of actions that a change actually consists of. None of them specifies the pre-checks and post-checks that decide whether the network is fit to be changed and whether the service survived the change. And none of them populates the inventory relationship that links an element to the services and customers that depend on it, without which neither the ITIL impact assessment nor the TM Forum API nor the regulator’s “ability to assess impact” has anything to compute with. That gap is the operator’s engineering work, and it is where the rest of this article lives.

Framework family	What it governs	What it leaves to the operator
ITIL 4, ISO/IEC 20000-1, COBIT, NIST CM controls	Change types, authority, schedule, approval evidence, post-implementation review, audit trail	How impact is computed, how a network change is tested, what a tested rollback is
TM Forum eTOM, ODA and Open APIs; Autonomous Networks levels	Process model, information model, system interfaces, measurable autonomy per scenario	Populating and keeping true the inventory and service model the APIs expose
ETSI ZSM, ITU-T autonomous networks	Closed-loop architecture, domain coordination, loop governance, sandbox for validation	The content of each loop: the procedure, the checks, the stop rules
Google SRE, DORA, GitOps	Progressive rollout, canarying, automated rollback, change failure rate, procedures as versioned code	Translation from software deployment to multi-vendor network elements and physical work
Ofcom guidance, UK security code of practice, NIS2 and its implementing rules, FCC, ACMA, CRTC	Legal duty to test, stage, roll back, monitor and report; sanction after failure	Every technical control the duty refers to

3. Redesigning change management end to end: from tickets to governed state transitions

The frameworks of section 2 and the ten stages of sections 4 and 5 describe how change management works today, and the rest of this article explains how to make each stage safer, faster and more autonomous. Before doing that, it is worth asking the question the automation roadmaps skip. If an operator designed its change process from scratch today — with a trusted inventory, a dependency graph, continuous observability, orchestration and AI already available — would it organize the work the same way? The answer is no. It would keep most of the controls. It would not keep the same activities, sequences, approvals, departmental boundaries or tools, because most of those exist to compensate for the absence of exactly the capabilities that are now available.

Why automating the existing workflow is not enough

The ten-stage process is a product of its constraints, and it is a good design for the constraints that produced it. It was built for a world in which the inventory lived in several systems that did not talk to each other, in which impact was known only to the people who ran each domain, in which risk could not be computed and therefore had to be judged in a meeting, and in which the only way to be sure a check had happened was to make someone sign that it had. Under those constraints the rational structure is a sequence of handoffs between specialists, with approvals as the control of last resort. That is what the ten stages are.

Automating each stage in place keeps the structure and accelerates it, which is not the same as improving it. An impact analysis computed by a graph in seconds and then left for two days in a planner’s queue has saved seconds. An approval routed automatically to the same board, with the same form, has digitized a bottleneck. A procedure reviewed by a language model and then executed from a PDF at a terminal has automated the safe half of the work and left the dangerous half untouched. The hyperscaler practices in section 11 are instructive precisely because none of them is an automated change advisory board: Meta, Google and Microsoft did not accelerate their approval workflows. They replaced approvals with gates, judgement with policy and sequential review with continuous verification, and they kept the people for the exceptions.

The redesign therefore begins with a distinction that automation roadmaps blur: between controls, which must remain, and administrative work, which exists only because the systems were never integrated. The controls are the ones the investigations of section 1 found missing:

• Controls that remain — independent review of the procedure; representative testing before the window; staged execution with the ability to stop; a tested way back; verification on the service rather than on the element; segregation of duties; an auditable record.
• Administrative work that goes — re-keying information from one system into another; chasing domain teams for impact opinions the graph can compute; collecting approvals for changes whose risk is already known; status meetings that exist to synchronize people who could be synchronized by a shared state; manual collision checks against a calendar; updating the inventory after the fact.

The unit of work: a governed state transition, not a ticket

In the traditional model the unit of work is the ticket, and the process is the set of activities that move it. In the redesigned model the unit of work is a transition of the network from one state to another. A transition has a defined set of elements, a current state and a target state, a declared outcome, a set of constraints — risk limits, windows, services that must not be degraded, the recovery time the business tolerates — and the evidence that will prove it happened as intended. The ticket does not disappear. It remains the trace for audit and the integration point with service management, and the change request of the TM Forum API already carries most of these fields. What disappears is the need for people to move it by hand through ten stages.

The target operating model has four parts, and the organization’s role in each is different from today’s:

• Intent — the owner of the change declares the outcome and the limits: these elements, this target state, these services protected, this risk tolerance, this recovery time. Not the activities.
• Intelligent plan — the system assembles the proposal from the procedure catalogue, the dependency graph, the calendar and the live state of the network, states its confidence and its unknowns, and keeps the plan current as conditions change.
• Governed execution — the orchestrator executes catalogued procedures within policy, with stop rules armed and the authority to halt, and people decide the exceptions with the evidence in front of them.
• Continuous assurance — an independent assurance function proves the result on the service before, during and after the transition, and feeds what it learns back into the procedures and the risk model.

In this model the organization declares objectives, sets limits, resolves exceptions and supervises outcomes. It does not carry information between systems, and it does not approve what policy can decide. This is the intent-driven pattern that the standards bodies have been specifying for the network as a whole — TM Forum’s intent management interface and ETSI’s intent-driven closed loops — applied to the one operational scenario in which the distance between the intent and the activities is widest (TM Forum TMF921; ETSI GS ZSM 016, Intent-driven Closed Loops).

Taken to its conclusion, the entry point of the process stops being a technical instruction and becomes a business or service objective. Today a change begins with “upgrade the software on these nodes”, “modify this policy”, “migrate this equipment”. In the target model it can begin with something closer to the actual requirement: modernize these network elements before the end of the quarter, maintaining continuity of the critical services, respecting the capacity constraints and minimizing customer impact. From that objective the system helps build the change plan, identifies the dependencies, computes the risk, proposes the sequence, executes through governed workflows and verifies continuously that the service conditions still hold. That is no longer workflow automation; it is intent-driven change management with closed-loop assurance, and the industry has begun to specify it as such rather than leaving it to each operator to invent.

Six design changes, and the one that matters most

Dimension	Traditional process	Redesigned with AI
Entry of work	An engineer prepares a request and fills in forms; completeness depends on the engineer	The owner expresses the objective; the system identifies what it needs, resolves the elements against the inventory and builds the proposal; an agent interprets incomplete requirements and flags inconsistencies
Impact assessment	Separate queries to inventories, specialists and affected areas; answers arrive by e-mail, days later	One integrated analysis across topology, resources, services, customers, redundancy and live state, with coverage and confidence stated
Planning	A sequence of reviews, meetings and validations between teams	An optimized plan that weighs risk, dependencies, windows, recoverability and other work, recomputed when conditions change
Decisions and authorizations	A relatively uniform approval circuit and a periodic board	Authority proportional to risk; routine decisions taken by policy; exceptions escalated to named people with the evidence
Execution	A procedure executed by hand, with separate checks	Versioned, verifiable, executable procedures supervised by stop rules
Verification and learning	Technical checks, ticket closure, a review some weeks later	Assurance integrated before, during and after; inventory updated as a step; procedure and risk model improved from evidence

The sixth row changes the economics and the second changes the safety, but the design change that matters most is not in the table, because it is about time rather than activity. In the traditional process the analyses are sequential and static: impact is assessed, then collisions are checked, then risk is scored, then a window is proposed, and each result is a snapshot that nobody revisits. In the redesigned process they are computed together and kept live. An approved change is re-evaluated continuously against the network as it is tonight, not as it was when the form was filled in, and a change whose redundant path failed this afternoon is blocked automatically, before anyone on shift has to remember that the two are related. That single behaviour — continuous re-evaluation of an approved change against live state — prevents the class of outage in which two individually safe interventions remove both halves of a redundancy, and it is impossible in a process whose analyses are documents.

One change, two operating models

A concrete example shows what disappears and what does not. The change is a software upgrade on several nodes of the mobile core that carry voice and data, including emergency calls — the kind of change that opened this article.

As it runs today. An engineer in the core team writes the request, attaches last quarter’s procedure with the version numbers edited, and declares the affected services from memory. A planner reads it two days later, queries the resource inventory, e-mails the transport and IP teams to ask whether anything else is planned, and books the change for the following week’s board. The board approves it with the same form and the same ten minutes it gives every change. On the night, a technician executes the procedure from a document at a terminal, runs the pre-checks and interprets them, upgrades the nodes one by one, runs the post-checks and closes the ticket at four in the morning. The inventory is updated the following week, or when someone notices. If the protection path of one of the nodes failed the previous evening, nobody in this chain finds out unless the technician happens to look. Counting generously, the change passes through six handoffs, waits at four of them, and is verified on the element rather than on the service.

Redesigned, the same change runs in six steps.

1. The system builds the proposal. The core engineer declares the intent: these nodes, this target version, continuity of voice and data within the authorized risk limits. The system identifies the elements, versions, configurations and the approved procedure from the catalogue; an agent flags that the declared service list omits a wholesale voice customer the graph says depends on two of the nodes.
2. It computes impact and prepares the plan. It walks the dependency graph, identifies the services and customers exposed, checks the live state of the redundancies, finds a transport maintenance that overlaps the proposed window on a shared-risk group, and proposes a sequence and a different window.
3. It validates the change and sets its limits. The procedure matches the catalogue, the rollback is classified reversible and was tested on this version, static validation and formal verification pass, and policy sets the authorization level: because emergency calls are exposed, a named engineer and the assurance function must approve, with the evidence in front of them.
4. The orchestrator executes in stages. One node, a checkpoint, then the rest. An independent assurance function watches technical and service indicators against the baseline captured before the first step.
5. The approved stop rules decide. A checkpoint shows call-setup latency drifting on the first node. The system holds the next stage; an agent assembles the diagnosis and the evidence; the engineer on duty chooses between the catalogued recovery and a hold. Policy would have allowed automatic rollback only if the attribution were unambiguous and the rollback reversible, and tonight it is neither.
6. The result is verified and learned from. The service is verified against the baseline, the inventory is updated as a step of the procedure, the evidence is stored, and the overrun at step four becomes a revision of the procedure and a feature in the risk model.

The difference is not that the second version has agents. It is that most of the coordination, analysis and preparation happens without handoffs between departments while the people keep the decisions that matter — and that the one decision in this example which the traditional process would have got wrong, the overlapping transport maintenance, is caught by a query rather than by luck. Swisscom’s proof of concept, described in section 11, in which an engineer submits the change in natural language and agents compute the blast radius, plan the tests, execute them on a twin and attach the verdict to the ticket, is the first three of these steps running inside an operator (Outshift by Cisco, Swisscom case study, 2025).

Activity	As-is	To-be	What happens to it
Writing the request	Engineer, forms, memory	Declared intent; system-built proposal	Transformed: people declare, the system assembles
Impact and collision analysis	E-mails to domains; days	Graph query; seconds; kept live	Automated and made continuous
Approval	Weekly board, uniform	Policy; people for exceptions and critical services	Becomes policy; human where judgement adds something
Execution	Technician, document, terminal	Orchestrator, catalogued procedure, stop rules	Automated and supervised
Post-checks	Executor interprets outputs	Assurance verifies the service against the baseline	Transformed: independent and service-level
Inventory update	Later, by someone	A step of the procedure	Eliminated as a task; kept as a result
Status meetings and chasing	Daily	None; one shared state per change	Eliminated

Four operating modes, assigned by risk and by conditions

A telecom operator should not design one process. It should design four operating modes and a rule for assigning changes to them. A routine parameter change and an upgrade of the core that carries emergency calls do not deserve the same controls, and treating them the same is how boards end up rubber-stamping the second in order to get through the first.

• Standard and repetitive changes — pre-authorized procedures, evidence generated automatically, execution without individual approval whenever every condition of the policy holds. Bell Canada’s catalogue of pre-agreed change types, exposed to partners through the standard API, is what this mode looks like at the interface (Bell Canada, 2023).
• Intermediate-risk changes — automated preparation and validation, a human decision taken on the evidence, supervised execution with checkpoints and stop rules.
• Critical, exceptional or uncertain-recovery changes — reinforced analysis, explicit human authorization, engineering and assurance in the loop, simulation where it adds information, direct supervision throughout.
• Emergency changes — an urgent need to restore service or mitigate a risk, with the assessment compressed rather than skipped, a named authority reachable at any hour, mandatory traceability of what was done and why the normal path was not followed, and a review afterwards. The frameworks are unanimous that emergency does not mean no rules, and the European implementing rules go further and require the reason the procedure could not be followed to be documented alongside the result. The operational test of a change capability is not how it handles its standard changes; it is whether its emergency path produces the same evidence as its normal one.

The assignment is not by change type alone, and this is where the redesign differs from a tiering exercise. It depends on the state of the network at the time, the criticality of the services exposed, the quality of the data the analysis ran on, and the demonstrated recovery capability of the procedure. A change that is normally automatic moves up a mode if its protection partner is degraded, if the exposed services include regulated functions tonight, if the inventory coverage for the affected elements is incomplete, or if the last execution of the procedure on this platform overran its rollback budget. The execution modes of section 7 describe who runs the steps; the operating modes here describe how much of the whole lifecycle the system is allowed to own for a given change on a given night. The second is what the risk algorithm that downgraded Rogers’ sixth upgrade phase from high to low got wrong: it moved a change down a mode because earlier phases had succeeded, not because the conditions had been verified.

How to approach the redesign in a real operator

The redesign does not start by selecting an agent framework or defining a catalogue of twenty agents. It starts by reconstructing what actually happened to the changes executed in the last six to twelve months. The requests, the waits, the approvals, the consultations, the validations, the incidents that followed and the work that was repeated. Where the service-management and orchestration logs are rich enough, process mining does this at scale; where they are not, incident analysis, operational interviews and language models over the ticket corpus find the patterns — the change types that always wait at the same step, the approvals that never reject, the checks that never fail, the domains that are always asked and never answer in time.

From that picture, two representative scenarios are enough to design the target process. One high-volume change type with bounded risk, where the gain is throughput and the proof is that nothing broke; and one complex, cross-domain change with service implications, where the gain is safety and the proof is that the analysis caught what the old process would have missed. For each, the to-be process is designed before any agent is chosen, around six questions:

1. Which activities disappear entirely, because the information they produced is now a query?
2. Which decisions become policies, with the evidence that lets policy decide and the thresholds at which it escalates?
3. Which information is obtained automatically from the inventory, the graph, the calendar and live state, and what is the confidence of each source?
4. Which validations run in parallel rather than in sequence, and which must still wait for another’s result?
5. Where do people remain, and what exactly do they decide, with what evidence in front of them?
6. How is it demonstrated, for this change type, that the service was not degraded — which indicators, which baseline, which horizon?

The solution is then built on the shared capabilities the rest of this article describes, and the agents are components of that solution rather than the process itself. The inventory and the dependency graph (section 6), executable procedures (section 7), the orchestration layer that runs them across domains (section 8), policy and agents (section 9), validation and twins (section 10). The transformation is measured on two planes, and both must move: operational efficiency — end-to-end cycle time, human interventions per change, handoffs, the share of changes executed without a person in the loop — and safety and quality — change failure rate, incidents attributed to changes, time to detect impact, rollback reliability and inventory accuracy. A redesign that improves the first plane and not the second has moved risk rather than removed it; one that improves the second by slowing the first has not been adopted, it has been tolerated.

The organizational thesis

What this section adds to the architecture of the sections that follow is a claim about what change management is. In an operator whose operations are becoming progressively autonomous, change management stops being an administrative process of authorization and coordination and becomes an engineering capability that governs, executes and verifies safe transitions of the state of the network and its services. The consequences reach further than adding agents. The change function no longer manages each interaction; it owns the policies, the operating modes and the metrics. Engineering owns reliable, reusable, versioned procedures as a product. Systems provides the shared platform: inventory, graph, orchestration, evidence. Assurance evaluates, independently, the real effect on services. Governance decides what the system may do on its own and what requires a person, per change type and per condition, and revisits that decision on evidence.

The ten stages that follow are the components of that capability, and the sections after them are how each component is built. Read with the target model in mind, the question to ask of each stage is no longer “how do we automate this?” but “does this activity still need to exist, and if it does, who — or what — should own it?”

4. The lifecycle before the window: where most of the risk is decided

A change is not an event that happens in a maintenance window. It is a lifecycle of ten stages, and the window covers only two of them. The stages before the window — intake, impact analysis, collision control, the method of procedure, rollback preparation and authorization — decide most of the risk, because they decide whether the people executing the change know what depends on the element they are about to touch, whether the procedure has been tested, and whether there is a way back. The stages after the window — verification, watch and closure — decide whether a degraded service is noticed before customers notice it. The industry’s post-mortems are remarkably consistent on this point: the failures that became national outages were almost never execution errors in the narrow sense. They were decisions taken, or not taken, days earlier.

Stage 1 — Intake: a change request is a declaration of intent, not a ticket

The first failure of most change processes is that the request describes an activity rather than a transition between two states. “Upgrade the software on the core routers in region X” is an activity. “Move these twelve routers from version A to version B, with this configuration delta, affecting these services, between these times, with this fallback” is a transition that can be analysed, simulated, approved and verified. The intake stage exists to convert the first into the second, and a change process that accepts the first form as complete has already given up on the analysis that follows.

A normalized change request should carry a minimum set of structured fields, each of which can be validated against a system of record rather than read by a reviewer:

• Type and urgency — standard (pre-authorized, low risk, repeatable), normal (assessed and authorized case by case) or emergency (expedited, reviewed after the fact). ITIL 4 makes this classification the foundation of proportional governance, and it is what prevents the change authority from becoming a bottleneck that everyone learns to route around.
• Target elements — resolved against the inventory as identifiers, not free text. A request that names “the Madrid core routers” cannot be checked for collisions; one that names eight specific chassis can.
• Current and target state — software versions, configuration delta, capacity change, topology change. This is the field that makes dry runs and formal verification possible later.
• Services and customers in scope — initially as declared by the requester, later as computed from the inventory. The gap between the two is itself a quality signal about the request.
• Requested window and duration — including the time budget for rollback, which is routinely omitted and routinely the reason a window overruns.
• Procedure and fallback — a reference to a versioned method of procedure and a rollback plan, or an explicit statement of why neither exists yet.

The quality of the intake is measurable, and it should be measured. The share of change requests that are complete at first submission, the share that are returned for missing information, and the share that are re-classified during assessment are leading indicators of change risk that are available months before the change failure rate moves. Operators that have published their programme results tend to start here, for a practical reason: it is the only stage where the data problem is small enough to fix in a quarter.

Stage 2 — Impact analysis: from the element to the customer who notices first

Impact analysis answers one question: if this element behaves unexpectedly during or after the change, who is affected, how badly, and how quickly? The honest answer requires walking a chain of dependencies — from the physical or virtual resource being changed, through the topology it participates in, to the services that traverse it, to the customers and the regulated functions (emergency calls, hospitals, payment networks) that depend on those services. Every link in that chain is an inventory relationship, which is why the quality of the inventory sets the ceiling on the quality of impact analysis, a point developed in section 6.

The blast radius has two dimensions that are frequently confused: the static dependency set and the dynamic redundancy state. The static set is what the inventory says depends on the element. The dynamic state is whether, right now, the redundancy that is supposed to protect those dependencies is actually available — or whether the protecting path is itself degraded, in maintenance, or carrying the traffic of something else already failed. A change on a core router that would be routine with its redundant pair healthy becomes a single point of failure if the pair is out of service, and that condition is only visible if the impact analysis reads live state as well as inventory records.

Risk is a function of six factors, and reducing it to a single colour on a form loses the information that drives the decision:

Risk dimension	Question it answers	Source of the answer
Technical risk	Can the change itself fail?	Procedure maturity, vendor advisories, lab results, history of this change type
Service impact	Which services and customers are exposed, and which are regulated?	Inventory, service model, customer and SLA records
Concurrency	Does it collide with other changes, incidents, events or freezes?	Change calendar, incident system, event calendar, shared-risk groups
Timing	Is the window right for the exposed services’ traffic profile?	Traffic baselines, busy-hour data, business calendar
Recoverability	Can it be reversed or recovered within the tolerable time?	Rollback classification, tested recovery time, backups
Historical risk	What happened the last times this change type ran?	Change records, incident records, post-implementation reviews

Stage 3 — Collision and concurrency control: the calendar is a safety system

Two individually safe changes can be jointly catastrophic, and the mechanism is almost always the same: they remove both halves of a redundancy at the same time. A transport maintenance on one fibre path and a router upgrade on the node that the other path terminates on; a database migration in the service platform and a load balancer change in front of it; a firewall upgrade in one data centre during a software rollout in its disaster-recovery twin. None of these pairs looks dangerous in isolation. Each of them has produced an outage somewhere.

Collision control therefore has to look at four kinds of concurrency, not just the obvious one:

• Technical concurrency — changes on the same elements, the same shared-risk groups (the same duct, the same power feed, the same cluster) or the same protection pair, within overlapping windows.
• Geographic concurrency — multiple changes in the same region that together exceed the field or operations capacity to respond if several go wrong at once.
• Concurrency with incidents — an open major incident on a dependent service, or a degraded element in the dependency chain, should block or re-plan the change automatically rather than depend on someone remembering to check.
• Concurrency with events and freezes — business-critical periods, public events, regulatory deadlines, and the freeze windows that most operators define and few enforce consistently across domains.

The practical implementation is a change calendar that is queryable rather than viewable. A calendar that people look at catches the collisions that people happen to look for. A calendar exposed as a service — this is the problem that the TM Forum change management API is designed to standardize — can be queried by the impact engine for every new request: given these elements and this window, what else is scheduled on anything within two hops of them, on any shared-risk group they belong to, or on any service they carry? That query is simple once the inventory can answer “within two hops”, and impossible until it can. Service-management platforms already implement the simple version — conflicts on the same configuration item, on its parent or child items, and against maintenance and blackout windows (ServiceNow, conflict detection); the telecom version needs the two-hop and shared-risk query, which only the inventory graph can answer.

Stage 4 — The method of procedure: the contract between planning and execution

The method of procedure (MOP) is the most important artefact in the whole lifecycle and the one that frameworks say least about. It is the document — increasingly, the executable specification — that states exactly what will be done, in what order, with what expected result at each step, how the result will be verified, and how to get back to the starting point if any step fails. It is where the abstract change request becomes a sequence of commands, API calls and physical actions. The term comes from the operating practice of the large telephone companies and their equipment suppliers, and the tradition carries both its strength and its weakness: the MOP has always been a document written by an engineer for a technician, and it is usually still a document. The data-centre industry’s reference description of a good MOP — identification and version control, prerequisites and notifications, safety, tools, steps with expected results and initials, a back-out plan to a safe pre-defined state, and dry runs and walk-throughs before execution — is a useful checklist precisely because it is so rarely met in full (Uptime Institute Journal, “The Making of a Good Method of Procedure”).

A complete MOP has ten sections, and the quality of a change programme can be audited by sampling how many of them are actually filled in:

1. Identification — the change it implements, the elements, versions, domain, owners, and the MOP’s own version and approval history.
2. Objective — the initial state, the modification, and the expected end state, stated so that each can be verified.
3. Dependencies — other changes, platforms, licences, spares, vendor support and people that must be in place.
4. Preconditions — the window, access, backups and configuration snapshots that must exist before step one.
5. Pre-checks — health and service verifications with explicit pass/fail criteria, not just commands to run.
6. Execution steps — ordered, each with the command or API call, the expected output, the maximum duration, and whether it is a checkpoint at which the change can be paused or abandoned.
7. Post-checks — configuration verification and behavioural verification, against the baseline captured before the change.
8. Rollback — triggers, the inverse actions, the time they take, their own risks, and evidence that the rollback has been tested.
9. Evidence — what is captured at each step, where it is stored, and what the closing record must contain.
10. Governance — the approvals, the execution mode (manual, assisted, automated), the escalation path and the people authorized to stop the change.

Three practices separate a MOP that protects the network from one that merely documents the intent to change it. The first is peer review by someone who did not write it and who is senior enough to reject it; the absence of independent review was a specific finding of the regulator’s report on the 2024 nationwide wireless outage in the United States. The second is a dry run — in a lab, on a digital twin, or at minimum as a configuration diff produced by the orchestrator without committing — so that the first time the procedure is executed is not in production. The third is versioning: a MOP that is e-mailed as an attachment and edited in the window has no identity, and a change executed against an unidentified procedure cannot be audited, learned from, or automated.

The structural weakness of the document-form MOP is that every protective practice depends on a human doing it under time pressure. The pre-checks are commands whose output the technician interprets; the expected results are described rather than asserted; the rollback is a paragraph. The transition to an executable MOP — a structured specification whose pre-checks are assertions, whose steps are invocations with declared expected outputs, and whose rollback is tested code — is the single highest-leverage automation in the whole lifecycle, and it is where section 7 begins.

Stage 5 — Rollback preparation: reversible, recoverable or irreversible

“Rollback plan: revert the configuration” is the most common sentence in change requests and the least useful. It conflates three situations that need different preparation and different authorization. A change is reversible when restoring the previous configuration or software version is itself a tested, bounded operation — a routing policy change on a router with configuration rollback, a feature flag, a container image tag. It is recoverable when returning to service requires a contingency procedure with its own duration and risk — a database schema migration with a restore step, a hardware replacement, a firmware upgrade that cannot be downgraded without a reload. It is irreversible, in practice, when the way back is a new change: a data migration that has already received live writes, a numbering or addressing change propagated to third parties, a decommissioning.

The classification drives four concrete decisions that should be visible in the change record:

• The rollback time budget — reserved inside the window, after the last point at which the decision to roll back can be taken. If the window is four hours and the rollback takes ninety minutes, the change has a two-and-a-half-hour window, not four.
• The rollback triggers — the specific failed checks or KPI breaches that mandate reversal, decided before the window so that the decision in the window is a lookup, not a debate.
• The rollback test — for reversible changes, a demonstration that the inverse operation works on this software version and this hardware; vendors’ commit-confirmed and rollback mechanisms are only a safety net if someone has confirmed they behave as documented on the platform in question.
• The authorization level — irreversible changes deserve a different authority, a different window and usually a staged approach that converts them into a sequence of recoverable steps.

Multi-domain changes add a specific hazard: partial rollback. When a change spans a core network function, a transport path and an IT platform, reverting only the component that visibly failed can leave the end-to-end service in a state that none of the three domains has ever tested. The rollback plan for a cross-domain change is itself a cross-domain procedure, with its own ordering and its own verification, and it belongs in the MOP rather than in the judgement of whoever is on shift when the alarm comes in.

Because of that, the recovery strategy is not a single mechanism but one of five, and the procedure has to declare which one applies before the window opens. Naming the strategy in advance is what converts “rollback plan: revert the configuration” into a commitment with a time budget attached, and it is the difference between a rollback that is exercised and one that is assumed.

Type of intervention	Recovery strategy	What actually has to be proven	Realistic time budget
Simple configuration change	Automated reversion to the captured state, with commit-confirmed where the platform supports it	That the inverse operation works on this software version and this hardware	Minutes
Traffic migration	Controlled return to the previous routing or forwarding state	That sessions rebuild rather than revert, and that the original path still has the capacity	Tens of minutes
Multi-domain change	Coordinated compensation of the steps already completed, in reverse order	That a partial rollback does not leave the end-to-end service in a state nobody has tested	Hours
Non-reversible upgrade or migration	Recovery toward a defined safe state, not toward the previous one	That the safe state exists, is documented, and has been reached at least once	Hours to days
Physical intervention	Supervised recovery with field action	That spares, access and travel time are inside the window the service can tolerate	Hours to days

Stage 6 — Authorization: proportional to risk, based on evidence, never a signature on a form

The change advisory board is the institution that most operators associate with change governance, and it is also the institution that ITIL 4 explicitly stopped recommending as the default. A weekly committee that reviews every change produces two predictable pathologies: it becomes a bottleneck that teams route around by reclassifying changes as standard or emergency, and it reviews so many items that the review of any one of them is superficial. The alternative is not less control but proportional control: standard changes are pre-authorized through an approved model and audited after the fact; normal changes are authorized by the person or small group closest to the risk, with the evidence in front of them; only high-risk, cross-domain or irreversible changes reach a board, and that board sees few enough items to actually read the MOP. The evidence supports the shift: the DORA research finds that heavyweight, external approval processes are negatively correlated with delivery performance and do not reduce failure rates, whereas peer review and automated gates do (DORA, “Streamlining change approval”).

What the authority should see is evidence, and the evidence should be generated by the process, not assembled for the meeting. The computed impact set and its confidence; the collision query result; the MOP version and its review status; the rollback classification and the test result; the risk score and the factors behind it; and the history of this change type. An authorization gate that checks those artefacts exist and are current is a gate that can be partly automated: a request missing a tested rollback for a change classified as recoverable does not need a human to be told no. The human is reserved for the judgement call — the change that scores medium on every dimension and high on none, which is exactly the profile of most of the changes that went wrong.

Segregation of duties is the quiet requirement that regulators are starting to write down. The person who writes the procedure, the person who approves it and the person who executes it should not be the same person for anything above a standard change, and the systems that execute changes should enforce that with role-based access rather than with policy documents. The security codes of practice attached to recent telecom security legislation treat change control and privileged access as two faces of the same control, and the audit that follows an outage will read them that way.

5. The window: pre-checks, staged execution and service verification

Everything decided before the window is a prediction. The window is where the prediction meets the network as it actually is tonight. A change validated three days earlier can be unsafe thirty minutes before execution because a protection path went down yesterday, because an incident is open on a dependent platform, because traffic is higher than the baseline assumed, or because the inventory the plan was built on has drifted from the configuration that is actually running. The window therefore has its own control structure — pre-checks, a go/no-go decision, staged execution with checkpoints, post-checks, and a watch period — and that structure is what a well-run operations centre spends its night enforcing.

Stage 7 — Pre-checks and the go/no-go decision

Pre-validation during planning and pre-checks in the window are different controls with different questions. Pre-validation asks whether the plan is sound. Pre-checks ask whether the network, right now, is in the state the plan assumed. The second set has to run immediately before execution, on live data, and its result has to be binary: fit to proceed, not fit, or requires review by a named person. A pre-check that produces a wall of command output for a technician to interpret at two in the morning is not a control; it is a ritual.

Stated more precisely, a change needs two distinct decisions, and most processes collapse them into one signature. The first is the design approval: this change is appropriate, properly prepared, adequately tested and may be scheduled. The second is the operational permission to execute: given the state of the network in the minutes before the window, it is still safe to proceed. The first is a judgement about the plan and can be taken days in advance. The second is a measurement of reality and cannot. Separating them is what allows a change that was correctly approved on Monday to be blocked on Thursday night because a protection path failed on Wednesday, which is exactly the sequence that several of the investigations in section 1 describe and that none of the processes involved was able to interrupt.

The pre-check set for a network change has a recognizable shape across domains:

• Element health — hardware alarms, resource utilization, software state, log errors in the preceding hours, on the target and on its protection partner.
• Redundancy and capacity — the protecting path or node is up, is not itself in maintenance, and can carry the traffic that will fail over to it during the change.
• Incidents and collisions — no open incident on anything in the dependency chain; no new change scheduled since the last collision query.
• Service state — the KPIs of the exposed services are within their normal band, so that a post-change deviation can be attributed rather than inherited.
• Drift — the running configuration matches the inventory and the baseline the MOP was written against; a mismatch means the procedure may not apply to the element it is about to be run on.
• Readiness — access to the systems works, backups and configuration snapshots are taken and verified, the people and the vendor support named in the MOP are reachable, and the MOP version being executed is the one that was approved.

The baseline is captured at this moment, and its definition is a planning decision, not an afterthought. The KPIs that will be used to declare the change successful — sessions, routes, throughput, latency, loss, error rates, and the service-level indicators of the exposed services — are recorded before the first step, with enough history to know their normal variation. A post-check compares against this baseline; without it, “the KPIs look fine” means “the KPIs look like what I expected”, which is a much weaker claim.

Stage 8 — Staged execution with checkpoints and stop rules

The single most protective execution practice is also the simplest: do not change everything at once. One element, then a checkpoint, then the rest in stages; one region, then the next; one per cent of traffic, then ten, then all. The hyperscalers call this progressive rollout or canarying and have built their reliability engineering around it, and the mechanism is the same whether the change is a container image, a router configuration or a core network software load. The recent cloud outages that made headlines — a configuration change that propagated globally in minutes, a feature deployed to every region without a staged path — were not failures of testing so much as failures of staging: the change was correct in intent and wrong in detail, and nothing between the first affected element and the last gave anyone a chance to notice. Microsoft’s published safe-deployment practice — canary, then pilot, then progressively broader regions, with bake time between stages and automatic rollback on health signals — is the same discipline at cloud scale, and the US industry’s own best practice, cited by the regulator in the 2024 outage report, is to “verify complex configuration changes before committing them and test after the change” (Microsoft Azure, “Advancing safe deployment practices”; FCC, July 2024).

Checkpoints only protect if they have stop rules attached, and stop rules only work if they were agreed before the window. A checkpoint is a point in the MOP at which execution pauses, a defined set of checks runs, and a defined decision follows: continue, hold, roll back. The decision criteria — this KPI outside this band, this check failed, a new incident on a dependent service, the rollback time budget about to be consumed — are written into the procedure. The alternative, which is still the norm, is that the technician looks at the outputs and decides; under time pressure, with a window closing and a manager asking for status, that decision has a systematic bias toward continuing.

Transactional execution is the mechanism that makes staging cheap on modern network platforms. Model-driven orchestrators commit a change to every device and to their own database as one transaction — “if any of the device configurations fail, all changes will be rolled back” — and expose a dry run that shows the exact native-format delta before anything is sent (Cisco NSO documentation). Carrier-grade router operating systems implement the commit-confirmed pattern, in which a change reverts automatically unless an operator confirms it within a timer — ten minutes by default on two of the most widely deployed — so that a change that cuts off the management path undoes itself (Junos, commit confirmed; Nokia SR OS, commit confirmed). These capabilities are twenty years old in some platforms and still not used in many change processes, usually because the process was designed around a document and a terminal rather than around the orchestrator.

Stage 9 — Post-checks: five definitions of success that are not the same

“The change was successful” can mean five different things, and most outage post-mortems describe a change that met the first two and was closed before anybody tested the rest. Technical success means the element accepted the change: the commit went through, the software loaded, the configuration is as intended. Functional success means the element behaves as intended: sessions re-established, routes present, interfaces up, the feature works. Network success means the connectivity around it behaves as intended: routes converged, no loss or latency introduced on the paths that were re-computed, the alternative path carrying what it was meant to carry. Service success means the services that traverse the element perform within their objectives for their customers. Business success means the change achieved its purpose without unacceptable side effects. A post-check that stops at the second definition has verified the change and not the service, and the gap between the second and the fourth is where the examples in this article keep ending up: every command succeeded, every interface came up, and the customers noticed anyway.

Level of success	What is verified	Typical evidence	Who verifies
Technical	The element accepted the change	Commit result, version string, configuration diff equals zero against target	Executor, orchestrator
Functional	The element behaves as intended	Sessions, adjacencies, routes, interface state, feature tests	Domain engineering
Network end to end	The connectivity around the element behaves as intended	Convergence time, forwarding paths, loss, latency, jitter, utilization of the alternative path	Domain engineering with assurance
Service	Exposed services perform within objectives	Service KPIs and SLIs against the pre-change baseline, per service and per customer segment	Service assurance
Business	The purpose was achieved without unacceptable side effects	Capacity delivered, feature enabled, cost removed; complaints, churn signals, regulatory incidents	Change owner, service owner

Service verification has to run on more than one time horizon, because the damage from a change does not always appear in the window. Some effects are immediate: a routing policy that withdraws prefixes, a firewall rule that blocks a signalling port. Some appear under load: a software version with a memory leak or a session-table limit that is only reached at the morning peak. Some appear days later: a certificate that was not renewed as part of the change, a timer that expires, a batch job that depends on a path that no longer exists. A verification regime that checks at fifteen minutes and closes the record is calibrated for the first class only.

• Immediate (minutes) — technical and functional checks, plus the fast service KPIs: sessions, call setup, throughput, loss, latency on the exposed services.
• Short-term (hours) — stability under rising traffic, anomaly detection on the exposed services against the baseline and against control groups of equivalent elements that were not changed.
• Delayed (days) — for changes whose failure modes are known to be deferred: software upgrades, certificate and licence changes, capacity changes that will be tested by the next busy period.

Attribution is the hard problem in post-change verification, and getting it wrong in either direction is costly. A service degradation that starts after a change is not necessarily caused by it — other changes, traffic events and independent failures happen on the same night — and rolling back a change that was not the cause wastes the window, delays the real diagnosis and can make the incident worse. Conversely, declaring a degradation “unrelated” because the change passed its functional checks is how outages get closed as incidents and investigated separately, with the causal link discovered a week later. A credible verification system therefore reports two things: the magnitude of the deviation, and the strength of the evidence linking it to the change — temporal proximity, topological proximity through the dependency graph, consistency with the change’s known failure modes, and the absence of competing explanations. That is a job for the correlation and causal-analysis machinery of service assurance, and it is the point at which change management and assurance stop being separate processes.

Stage 10 — Closure and learning: the change updates the inventory, or the inventory starts lying

Closure is where change management either feeds the system of record or quietly corrupts it. Every change alters something the inventory is supposed to know — a version, a configuration, a capacity, a topology, a dependency — and if the closing step does not write that alteration back, the next change’s impact analysis runs on stale data. Change management is simultaneously the biggest consumer of the inventory and its biggest source of drift, which is why the executable MOP, which can update the record as a step rather than as a chore, matters as much for data quality as for execution safety.

The closing record should contain the evidence rather than a summary of it: the pre-check and post-check results, the baseline and the post-change KPIs, the configuration before and after, the MOP version executed, the deviations from it, the timing of each step against the plan, any rollback or partial rollback, and the incidents opened during the watch period. That evidence is what makes the post-implementation review a review rather than a conversation, and it is what trains the risk models described in section 9: a change failure rate is only a useful number when every failure in the numerator has a record detailed enough to say why.

Two learning loops close the lifecycle. The fast loop updates the MOP: a step that took three times longer than planned, a pre-check that produced a false alarm, a rollback that did not behave as documented, each becomes a revision in the catalogue rather than a story told at the next shift handover. The slow loop updates the risk model and the change models: which change types fail, on which platforms, under which conditions, and which of the pre-checks actually predicted trouble. Operators that have moved up the autonomy scale for change management describe this second loop as the point at which the programme stopped being a process improvement and became an operational capability.

A worked example: migrating traffic off a broadband network gateway

The controls of this section are easier to judge against a concrete change, and one of the most common in a fixed network makes the point better than a routing policy. An operator needs to move subscriber traffic off a broadband network gateway or a provider edge router onto an alternative, so that the device can be upgraded or replaced, and then move it back. The intervention carries residential traffic and a set of business services. It is reversible in principle and unforgiving in practice, because the thing that moves is not a configuration but tens of thousands of live sessions.

Stage A, readiness. The dependency graph resolves which services and which business customers ride on the gateway, the capacity of the target device is computed against the traffic that would move, and the analysis establishes what proportion can be shifted without pushing the alternative path past its utilization threshold. This is where the redundancy question of section 4 stops being rhetorical: physical redundancy does not by itself guarantee either the capacity or the service continuity of everything that depends on the device.

Stage B, the go/no-go that a document-driven process would have passed. At five minutes before the window the pre-checks find rising error counters on one interface of the alternative path. In the traditional process this surfaces only if the method of procedure happened to include that check and the technician happened to read it carefully at two in the morning. With the controls described above, the change is blocked automatically, re-evaluated, and cleared only once the condition is understood. The authorization held; the permission did not.

Stage C, the progressive move. Rather than shifting all traffic at once, the procedure moves a small share of sessions first — the granularity depends on what the platform and the service architecture allow — and verifies capacity, session counts, errors, loss and latency before widening to a larger share and then to the remainder. The important consequence is conceptual rather than mechanical: the method of procedure stops being a fixed sequence of actions and becomes a procedure conditioned by operational evidence, in which the decision to proceed to the next stage is computed rather than assumed.

Stage D, the degradation that the technical post-check would have missed. The configuration applies cleanly, the sessions establish, the interfaces are up and the adjacencies form. Packet loss on the migrated traffic nonetheless begins to rise. A purely technical verification reports success, because by its own definition the change succeeded. The assurance layer sees a deviation against the baseline, correlates it with the intervention in progress, checks whether competing explanations exist, and establishes which stage is the probable cause. Only then does the orchestrator receive a controlled instruction to hold the next stage or to recover.

Stage E, recovery and closure. The recovery here is the second row of the table above, not the first: traffic returns to the previous path under control, sessions rebuild rather than revert, and the verification that matters is whether the service recovered rather than whether the configuration was restored. The procedure is then revised from what happened, and the revision is what the next execution inherits. This sequence — observe, detect, diagnose, decide within policy, act through a catalogued recovery, verify the recovery, learn — is the closed loop of section 9 instantiated on a single change, and it is bounded in a way that general closed-loop automation is not, because the system knows exactly what changed, when, and what the undo is.

6. The inventory: the foundation that makes impact analysis possible at all

Every stage described so far — impact, collisions, pre-checks, attribution, closure — asks the same question in a different form: what depends on this element? That question has exactly one source of answers, and it is not the change management tool. It is the inventory, in the broad sense: the resource records, the topology that connects them, the service model that says which services ride on which resources, and the customer model that says who buys those services. If the inventory cannot answer the question, no change process can, and no amount of AI layered on top will produce an answer that is better than a guess with good grammar.

Four artefacts that change management needs, and usually gets only one of

“The inventory” is four things, and most operators have a mature version of only the first. The resource inventory records what exists: chassis, cards, ports, optical modules, virtual machines, containers, cells, licences. The topology records how those things connect: links, paths, adjacencies, shared-risk groups, protection relationships. The service inventory records what the resources are for: which VPN, which wavelength service, which voice trunk, which 5G slice traverses which path. The customer and SLA model records who depends on each service and what they are owed. Impact analysis for a change needs all four, joined; a change process that has only the first can tell you that a chassis exists, which was never in doubt.

What the four artefacts have to produce, joined, is not an inventory listing but a dependency map of the change, and the test of whether an operator has one is whether it can answer seven questions about a specific element before an engineer touches it. Knowing the configuration of a backbone router is not the same as knowing what depends on it. The information required spans physical interfaces, transport relationships, routing and label-switched paths, business services, residential traffic, mobile backhaul, protection mechanisms and the platforms that sit behind them.

Question about the element	What the answer decides	Where the answer comes from
Which services depend on it?	The boundary of the potential impact	Service inventory joined to the topology
Which business customers are attached to those services?	Service levels, criticality and who has to be told	Customer and contract model
Is the redundancy effective right now?	Whether the change can proceed without interruption at all	Live state, not the design document
What capacity does the alternative path have?	Whether moving the traffic creates congestion during the work	Traffic matrix and utilization baselines
Are there active incidents on anything in the chain?	Whether to postpone rather than proceed	Incident system joined to the graph
Does it coincide with other work on the same service chain?	Accumulated risk across individually safe changes	Change calendar queried by dependency, not by element
What happened in equivalent changes before?	The prior probability of failure and the precautions to add	Change and incident history

The TM Forum information model and its open APIs provide the vocabulary for keeping these four consistent across systems. The resource inventory API (TMF639), the service inventory API (TMF638) and the change management API (TMF655) define, respectively, how resources, services and change requests are represented and exchanged between an operator’s systems and its suppliers’ tools. They do not populate anything; they make it possible for an impact engine, a change tool and an assurance platform to agree on what a “service” is and which resources it references. For an operator assembling a change capability from several vendors, that agreement is worth more than any individual feature.

Accuracy, staleness and the honest handling of unknowns

The failure mode is rarely that the inventory is empty. It is that the inventory is confidently wrong. Records that were accurate when created and never updated; dependencies that exist in the network and were never modelled because nobody needed them for billing or provisioning; a topology refreshed nightly from a network that reconfigures itself hourly; services mapped to resources at order time and never re-mapped after the resources were migrated. Each of these produces an impact assessment that is specific, confident and incomplete — and incomplete is worse than empty, because an empty assessment makes people ask questions and an incomplete one makes them stop.

The published figures on inventory accuracy are few, mostly vendor-sponsored, and consistently bad. Forrester reported in 2022 that more than half of the organizations it surveyed did not trust their configuration management database (Forrester, 2022); a 2026 survey of telecom operators commissioned by an inventory vendor found that only 13% said more than three-quarters of their network records were accurate (IQGeo and Vanson Bourne, 2026, vendor survey); and TM Forum’s 2026 reconciliation catalyst with SaskTel and Entel is titled, without irony, “if your inventory is wrong, your network decisions are wrong” (TM Forum Inform, 2026). No independent study links inventory error rates to change failure rates directly; the inference is the only honest statement available, and it is not a difficult one.

Three disciplines keep the inventory usable for change decisions:

• Discovery and reconciliation — the running network is read directly (configuration, routing state, controller north-bound interfaces, platform APIs for cloud-native functions) and compared against the records, with discrepancies queued, owned and resolved rather than tolerated. The pre-change drift check in section 5 is this discipline applied to one element at one moment.
• Change-driven updates — every closed change writes its effect back into the record as a step of the procedure, so that the biggest source of drift becomes a source of truth. This is the reason executable MOPs improve inventory quality as a side effect.
• Explicit confidence — relationships carry a confidence and a validity interval, and the impact engine reports its coverage. “Twelve services identified, confidence high for nine, two relationships unverified since last quarter, one element with no service mapping” is an actionable assessment; “twelve services affected” is not.

The rule that follows is simple and unpopular: absence of information is not absence of impact. An element with no service mapping in the inventory is not an element that carries no services. It is an element whose services are unknown, and a change on it should be treated as higher risk than a change on a fully mapped element, not lower. Change processes that score unmapped elements as low risk — because the impact engine returned nothing — are the ones that discover a hospital’s connectivity rode on a “spare” circuit.

The graph is the asset; the tools are replaceable

The operators that report credible results in change automation share a structural choice: the dependency model is owned centrally, as a graph, and consumed by every process rather than rebuilt inside each tool. The same resource-to-service-to-customer graph serves impact analysis for changes, root-cause analysis for incidents, blast-radius estimation for security events and capacity planning. Built once, kept true by discovery and by change closure, it is the most reused asset in network operations; built separately inside the change tool, the assurance tool and the planning tool, it is three inconsistent answers to the same question. The economics of the change programme follow from this: the inventory work is front-loaded and shared, and the marginal cost of each automated stage falls as the graph matures. The network-automation community’s “source of truth” discipline is the right model for the records layer: the system of record holds the intended state, the running network is read separately, and the difference between them is a managed queue rather than an unknown — the open-source inventories that popularized the term are explicit that live state should be compared against the intended record, not imported into it (NetBox documentation; Network to Code, “Source of Truth”).

7. Automating the lifecycle: from digitized forms to executable procedures

Three things get called “change automation”, and they are not the same project. The first is digitization of the procedure: replacing e-mail, spreadsheets and manual checks with a workflow tool that routes requests, records approvals and tracks status. The second is automation of the work: executing validations and network actions through orchestrators, APIs and pipelines rather than through terminals and hands. The third is intelligent autonomy: using machine learning and language models to interpret requests, assess risk, review procedures and verify outcomes, and agents to coordinate the automated capabilities. The third does not substitute for the first two; agents coordinating an undigitized process over an unreliable inventory produce a sophisticated interface to a traditional mess.

Lifecycle stage	Rules and workflow (digitization)	Orchestration and pipelines (automation)	Machine learning and agents (autonomy)
Intake	Structured fields, mandatory references, type-based routing	Element resolution against inventory, template lookup	Classification of free-text requests, extraction of intent, completeness scoring
Impact	Declared services, manual review	Graph traversal from element to customer, live redundancy state	Risk scoring from history, confidence-weighted impact, anomaly in the request itself
Collisions	Calendar, freeze rules	Queryable calendar, shared-risk group checks, incident-system integration	Prediction of resource contention and capacity to respond; proposal of alternative windows
MOP	Templates, mandatory sections, review workflow	Executable specification, dry run, config diff, version control	Consistency review, command/version compatibility, comparison with past executions, drafting from history
Rollback	Mandatory section, classification	Snapshot and commit-confirmed, tested inverse procedures	Classification suggestion, detection of untested or incomplete rollback plans
Authorization	Approval matrix by type	Automated gates on evidence (review done, rollback tested, no collisions)	Risk-based routing, explanation of the risk factors to the authority
Pre-checks	Checklist	Assertions executed on live state, baseline capture	Interpretation of ambiguous results, anomaly in the pre-change state
Execution	Manual with log	Staged, transactional, checkpoints with stop rules	Assistant interprets results, recommends continue/hold/roll back within policy
Verification	Post-check list	KPI comparison against baseline, control groups	Anomaly detection, attribution with evidence, rollback recommendation
Closure	Record and review	Inventory write-back, evidence store	Learning loop: MOP revisions, risk-model retraining, false-positive analysis

The executable MOP: the highest-leverage automation in the lifecycle

Converting the method of procedure from a document into a structured, versioned, executable specification is where change automation produces most of its safety return, and it is also where it meets most of its cultural resistance. The specification — in practice a structured file under version control, with parameters, assertions and invocations — does three things a document cannot. It can be validated before it runs: parameters checked against the inventory, commands checked against the platform’s software version, every step checked for a declared expected result. It can be dry-run: the orchestrator computes the exact configuration delta and the pipeline shows what would be changed without changing it. And it runs the same way every time, which means the second execution benefits from everything learned in the first.

Not every MOP needs to become code, and the attempt to convert everything at once is a common cause of programme failure. The catalogue of change types in a large operator follows a steep distribution: a few dozen types account for most of the volume, and a long tail of rare, complex, one-off procedures accounts for the rest. The frequent types — software upgrades of a given platform family, capacity additions, routing policy changes, parameter changes in the radio network, certificate rotations, firewall rule changes — are where executable procedures pay back in months. The long tail stays as documents, but documents with the same ten-section structure, so that the pre-checks and the rollback are at least explicit even when a person executes them.

The execution engine already exists on most network platforms; the process has to be redesigned around it. Model-driven orchestrators compute configuration deltas, apply them transactionally across devices with rollback on failure, and expose dry run and diff as first-class operations. Change-automation layers built on them go further and codify the MOP itself: playbooks with pre-maintenance snapshots, maintenance and post-maintenance phases, a dry-run mode, and a declared failure policy — complete rollback, rollback to a point, or abort — chosen before the play runs rather than during it (Cisco Crosswork Change Automation). Intent-based data-centre controllers stage a change against the intended model, check it semantically before deployment, and can return the whole fabric to a retained revision (Juniper Apstra, Time Voyager). General-purpose automation platforms provide check mode, diff and idempotent execution across heterogeneous infrastructure (Ansible, check mode). In the radio domain, the automation platforms’ applications cover configuration consistency checks, software and firmware upgrades, parameter validation and post-deployment acceptance testing, with lifecycle management integrated into the operator’s continuous-delivery pipeline (Ericsson, rApps). Cloud-native network functions are deployed through the same pipelines as any other software, with progressive rollout and automated analysis. What is missing in most operators is not the engine but two things above it: the catalogue of approved, reviewed, versioned procedures that the engine is allowed to run, and a layer that can run a procedure across several of these engines at once under one policy. The first is engineering discipline; the second is the orchestration layer of section 8.

Four execution modes, assigned by risk and recoverability rather than by ambition

The question is never “should changes be automated” but “which change types, at which execution mode, under which evidence”. Four modes cover the practical range, and a mature programme has change types in all four at once:

Execution mode	Who executes	Human role	Suitable for	Evidence required to enter the mode
Manual, assisted	Engineer or technician	Executes every step; tooling validates and records	Rare, complex, one-off or partly physical changes	Structured MOP, pre-checks and rollback explicit
Semi-automatic	Orchestrator, with human checkpoints	Authorizes each checkpoint; can stop at any time	Significant changes with repeatable procedures	Executable MOP, dry run, tested rollback
Automatic, supervised	Orchestrator end to end	Watches; can stop; reviews afterwards	Frequent changes with controlled risk	Measured success rate over a meaningful sample; stop rules proven
Autonomous under policy	System, within authorized bounds	Sets policy; audits	Standard changes, bounded, with demonstrated recovery	Change failure rate and false-stop rate within thresholds; rollback exercised in production

The mapping to the TM Forum autonomy levels is direct and useful for planning. Level 2 — the system executes, people decide — corresponds to semi-automatic execution; Level 3 — the system also perceives and decides within a scenario, people handle exceptions — corresponds to supervised automatic execution with system-driven stop rules; Level 4 — the system handles the scenario end to end including exceptions, people set intent — corresponds to autonomy under policy for defined change types. An operator does not have a Level 3 change process; it has some change types at Level 3, more at Level 2 and most at Level 1, and the programme’s job is to move specific types up the ladder with evidence.

8. The orchestration layer: the missing middle between the ticket and the device

Section 7 described the executable procedure and the engines that can run it. It did not answer the question that decides whether a change programme is buildable: which system is responsible for running a change that touches six domains, four tools and three teams? Most operators discover that the honest answer is “a person with a spreadsheet and a conference bridge”, and then try to fix it by buying either a better ticketing system or a better device-configuration tool. Neither is the missing piece. The missing piece is a layer between them whose job is neither to govern the change nor to configure the equipment, but to execute the procedure across whatever systems the procedure touches, under policy, with evidence.

Three responsibilities that tool categories habitually blur

Governing a change, orchestrating it and executing it are three different responsibilities, and the confusion between them is the most common architectural error in change automation programmes. Governance owns the request, the risk policy, the authority and the audit trail; it is what service-management platforms do well and what they should keep doing. Execution owns the configuration of a specific device, service or platform; it is what model-driven orchestrators, router operating systems, automation playbooks and cloud APIs do well, each within its own domain. Orchestration owns the procedure: the ordered invocation of several execution systems, with the checks between the steps, the dependencies, the stop rules, the recovery paths and the evidence. It is the layer that most operators do not have, and the reason their methods of procedure are still documents.

Responsibility	What it owns	Typical systems	What it must not try to own
Govern the change	Requests and intent, risk policy and tiers, authority and approvals, calendar and freezes, audit and accountability	Service-management platforms	The technical sequence of a cross-domain procedure
Orchestrate the change	Executable procedures, pre-checks and post-checks, sequencing and dependencies, stop rules and rollback paths, evidence capture, policy enforced at execution time	Network and infrastructure orchestration platforms; in-house workflow engines	Being the inventory, the impact engine or the assurance system
Execute the change	Configuration of a device, a service, a platform or a cloud resource, transactionally where the platform supports it	Model-driven orchestrators, router operating systems, automation playbooks, radio automation applications, cloud and OSS APIs	The organizational process that surrounds the configuration

The boundaries are not absolute, and pretending they are is how operators end up paying twice for the same capability. Service-management platforms ship workflow engines and conflict detection; model-driven orchestrators ship transactional multi-device commit and rollback; orchestration platforms ship approval routing and ticket integration. The design question is therefore not which product covers the most boxes but which system is accountable for each boundary, and the rule that keeps an architecture coherent is simple: one system holds the state of the change, one system decides whether an action is permitted, and one system is accountable for each action actually reaching the network. An operator that already runs a model-driven orchestrator across its IP estate does not need a second platform to configure routers. It may well need one to run the twelve-step procedure in which configuring the routers is step seven.

What the orchestration layer actually does for a change

Nine capabilities describe what this layer contributes, and it is worth separating them by how much they depend on artificial intelligence, because eight of the nine do not depend on it at all. The vendors in this category now market the whole set under labels such as governed or unified change management, and the framing is accurate as far as it goes: the contrast they draw is between a change split across teams, tickets and tools, and the same change run as one workflow that calls every tool in sequence with validation and rollback built in (Itential, governed change management).

Capability	Traditional situation	What the orchestration layer contributes	Needs AI?
1. End-to-end orchestration	Each area executes its part and hands over	One flow coordinates the domains and the systems	No
2. Executable procedures	A written procedure interpreted by whoever is on shift	The automatable parts become verifiable tasks	No
3. Pre-checks and post-checks	Checks vary with the technician	Validations embedded in the workflow as mandatory steps	No
4. Rollback	A recovery plan written separately from the execution	Automated recovery paths bound to the failure they handle	No
5. Service-management integration	Tickets updated by hand, alarms suppressed by memory	Approvals, states, alarm suppression and evidence integrated	No
6. Governance	Rules that depend on who is responsible that week	Common permissions, conditions, controls and audit	No
7. Multi-domain execution	Coordination between specialists over a bridge	Common sequences that invoke each domain’s own tooling	No
8. Reuse	Isolated scripts and procedures per team	A library of components and flows reused across processes	No
9. Agentic execution	Manual decisions in variable situations	Agents that reason and invoke authorized tools within guardrails	Yes

The distinction in the last column is the one that most change programmes get backwards. An operator that builds capabilities one to eight has an industrialized change capability with or without a language model anywhere near it; an operator that starts at nine has an articulate interface to an unchanged process. A routine upgrade executed end to end with no generative AI in the path is not technologically behind. It is the thing the generative demonstrations are supposed to be building toward.

Reusable primitives: the library is the asset, not the workflow

The structural idea that makes this layer compound rather than accumulate is that procedures are composed from atomic, versioned actions rather than written as monoliths. Reading an interface state, looking up a route, comparing a running configuration against the intended one, capturing a snapshot, checking whether a redundancy is actually available, querying the inventory, reading a service indicator, opening a ticket, suppressing an alarm: each of these is written once, reviewed once, versioned, and then called by everything. The same interface check serves a fault diagnosis during an incident, a pre-check before a planned change and a verification step after a provisioning order. That reuse is what turns a portfolio of scripts into a capability, and it is the difference between an automation effort whose cost per use case falls and one whose maintenance burden rises.

The discipline that makes the library trustworthy is that the atoms are read-only first and are built as though no human would be present when they run. Diagnostics, state reads and comparisons come first because they are safe to call from anywhere and because they are what every other capability consumes; write actions follow, each with its own review, its own permissions and its own recovery path. The operator cases in section 11 that report the largest volumes describe exactly this sequence, and they also describe the governance that goes with it: every flow, whether a person or an agent starts it, passes through the same review, the same naming and adapter checks and the same role-based access controls. A library in which agent-initiated calls take a different path from human-initiated ones has two security models, which in practice means one.

Cross-domain execution: the delay is in the waits, not in the commands

An apparently simple change frequently requires coordinated action across IP, transport, cloud infrastructure, security, the operational support systems and the service platforms, and the time it takes is almost never dominated by the time the configurations take. It is dominated by the waits between teams, the switches between tools, the coordination errors and the badly synchronized sequences. A migration might need to invoke an IP orchestrator, wait for a virtualized platform to confirm, update security policies, validate connectivity, read the state of the service and close the record. Each of those actions takes minutes; the handoffs between them take days. The orchestration layer’s contribution is to keep the specialized system in each domain and coordinate their actions from a single procedure, which matters most precisely where it is hardest: in brownfield estates where the coexistence of generations of technology is not a transitional condition but the permanent state.

This is also the answer to the objection that automation requires replacing the installed base first. It does not. A procedure can call a twenty-year-old element manager through an adapter and a cloud-native function through its API in the same flow, and the quality of the result depends on whether the steps are verifiable, not on whether the systems are modern. What does have to be rebuilt is the procedure, and that is engineering work the operator cannot buy.

Governed execution: the board sets the policy, the platform enforces it

Section 4 argued that authorization should be proportional to risk and based on evidence rather than on signatures. The orchestration layer is where that argument becomes mechanical rather than cultural. Policy expressed as configuration — which change classes are pre-authorized, which risk tiers require which approvers, which windows are acceptable, which conditions block execution — is evaluated at the moment of execution rather than at the moment of the meeting. The vendors in this category are explicit, and correct, that this does not abolish the change advisory board: the board still defines what needs approval, what risk tiers apply and what windows are acceptable, and the platform enforces those decisions at execution time (Itential). The board’s work shifts from reviewing instances to certifying patterns, which is both a better use of senior engineering judgement and the only version of the board that scales.

The same mechanism closes a gap that the investigations of section 1 kept finding: the difference between an approval and a permission. An approval granted on Monday is a statement that the change is well designed. A permission to execute on Thursday night is a statement that the network is currently in a state where executing it is safe. In a document-driven process those two collapse into one signature, which is why a change approved before a protection path failed still goes ahead. When policy is enforced at execution time, the second decision exists as a separate, automatic gate, and the change that is no longer safe does not run.

What an orchestrator does not do, and why that matters

The honest assessment of this layer is that it is strong at four of the ten stages and dependent on other systems for the four that decide whether a change was wise rather than whether it was well executed. It enforces authorization, it automates pre-checks, it executes across domains and it captures post-checks and evidence. It does not know what depends on the element being changed, it does not optimize the window, it does not detect a service degradation, and it does not learn. Those capabilities come from the inventory and dependency graph of section 6, the planning logic the operator builds around the calendar, the assurance stack, and the analytics over the execution history. An orchestration platform consumes all four; it does not supply them.

Capability	Strength of the orchestration layer	What the operator still has to supply or verify
Workflow orchestration across domains	Very strong; this is the category’s reason to exist	Real coverage of legacy tooling and of each domain’s adapters
Executable procedures	Very strong	Converting and certifying the procedures themselves, which is engineering work
Service-management integration	Strong	A boundary with the corporate platform that does not duplicate ownership of the change state
Technical validation	Strong, through integrations	Which pre-checks exist for each platform and what they actually assert
Rollback	Strong as an orchestration capability	Whether each change type is genuinely reversible, and in what time
End-to-end service impact	Dependent on integrations	Service inventory, topology and the resource-to-customer relationships
Impact prediction and simulation	Not a native capability	Verification tooling, emulation or a twin, per section 10
Window optimization	Partial; it enforces, it does not optimize	A planning engine with constraints, traffic profiles and risk
Real-time detection and root cause	Dependent on assurance	Telemetry, baselines, correlation and attribution
Continuous improvement	Provides the execution history	Analytics over outcomes and governance of the resulting knowledge

Two claims in this category deserve specific scepticism, and both appear in the marketing of every vendor in it. The first is automatic rollback described as a complete restoration of the previous state, including for multi-domain changes. Treat that as an announced capability rather than a universal guarantee: section 4’s classification exists because restoring a configuration is not the same as recovering a service, sessions rebuild rather than revert, a platform may have accepted writes that cannot be unwritten, and an element can sit in an intermediate state after a failed upgrade. For every workflow, somebody has to establish what restoring actually means. The second is the implicit suggestion that orchestration is intelligence. It is not. A platform will execute a badly designed procedure flawlessly, and if the inventory is stale or the impact analysis missed a dependency, the result is a failure delivered automatically, at scale, with a complete audit trail. Automation removes human variability; it also propagates design errors faster than any human could.

Build, buy, or use what is already installed

Before buying an orchestration platform, an operator should establish what its installed base already does, because three of the alternatives are usually already paid for. Service-management platforms already hold risk assessment, conflict detection against configuration items and maintenance windows, and approval routing. Model-driven orchestrators already hold transactional commit, configuration diff and rollback across devices. General-purpose automation platforms already hold idempotent execution, check mode and a library model. The case for a dedicated orchestration layer is not that these are inadequate; it is that none of them was designed to run a procedure that spans all three.

Option	Strengths	Limitations and open questions	When it is the right answer
Dedicated orchestration platform	Cross-domain workflow, integration breadth, governed execution, agentic layer	Licence cost, integration effort, real functional coverage of legacy domains	Many controllers, tools and domains that must be coordinated uniformly across hundreds of change types
Service-management platform plus automation	Governance, approvals, risk, calendar, traceability already in place	Multi-domain technical execution still has to be solved elsewhere	The bottleneck is governance and traceability rather than execution
Model-driven network orchestrator	Transactional configuration and service modelling, dry run, rollback	Needs a layer above it for organizational process and non-network systems	The change volume is concentrated in one network domain
Automation platform plus a workflow engine	Flexibility, reuse of existing playbooks, no new licence	The operator owns the development, the guardrails and the maintenance	Strong internal engineering and a tolerance for owning a platform
Integrated OSS suite	Potentially unifies inventory, orchestration and assurance	Programme scale, cost, integration risk and supplier dependence	A wider OSS transformation is happening anyway

What to demand in a proof of concept

The demonstration that decides this procurement should be a real change of genuine complexity, not a virtual-LAN change and three green screens. Nine questions separate a platform that will run an operator’s change portfolio from one that will run its simplest tenth:

Question	What the demonstration must show
Can it orchestrate a real multi-domain intervention?	A complete workflow with dependencies, running against the operator’s existing tools, not a reference lab
Can a service degradation stop an execution in progress?	A real or injected assurance event that halts the workflow between stages
Can it identify the services and customers exposed?	A working integration with the inventory and the dependency model, with its coverage stated
What rollback does it actually provide?	A deliberately failed step, the restoration, and the verification that the service returned
How does it handle an approval invalidated by changed conditions?	Readiness evaluated at execution time, and the change blocked because the network moved
How does it prevent incompatible executions?	Exclusions, locks and coordination between two changes that must not run together
How is the AI constrained?	Permitted tools, scoped permissions, limits and an audit of every tool call
What happens if the orchestrator itself fails mid-change?	State recovery and the fate of a procedure interrupted halfway through
What results can it evidence?	Named customers, incidents avoided, hours released and change success rates, with the basis of each figure

The eighth question deserves its prominence, because it is the one the automation itself creates. A change process whose execution depends on a platform has made that platform part of the critical path, and the failure of an orchestrator halfway through a staged migration leaves the network in a state that neither the old procedure nor the new one describes. The answer an operator should require is the same one it would require of any production system: the state of every in-flight change is persisted outside the engine, a procedure can be resumed or safely abandoned from its last checkpoint, and there is a documented manual path for the changes that were running when the platform stopped. The 2025 cloud outages in section 1 are the general case of this lesson, and the operator that disabled its own DNS automation worldwide after an automation-induced failure is the specific one.

9. AI and agents in the change process: what they do at each stage, and what they must never do

Artificial intelligence enters the change process through two doors, and conflating them is the most common design error in current programmes. Through the first door come statistical and machine-learning models: risk scoring trained on change and incident history, anomaly detection against baselines, change-point detection on service KPIs, graph algorithms over the dependency model. These are fast, cheap per decision, measurable, and they belong in the critical path. Through the second door come language models and the agents built on them: interpreting a free-text request, reviewing a procedure for internal contradictions, explaining a risk assessment to an approver, assembling evidence for a post-change decision, drafting a procedure from history. These are slower, more expensive, harder to measure, and they belong beside the critical path — advising it, never constituting it.

Seven agent roles, each with a hard limit

The useful way to design agents for change management is by responsibility and by prohibition, in that order. Seven roles cover the lifecycle, and each has a limit that should be enforced by the architecture rather than by the prompt:

Agent	Responsibility	What it reads	Hard limit
Validation	Interpret the request and the MOP; detect missing sections, inconsistencies between steps, pre-checks and rollback; check command syntax against platform version	Request, MOP catalogue, platform documentation, inventory	Cannot approve; cannot edit an approved MOP; flags, does not fix silently
Risk and impact	Walk the dependency graph, query collisions, compute a risk profile with its factors and confidence, compare with history	Inventory graph, live state, calendar, incidents, change history	Cannot assert relationships the inventory does not contain; must report coverage and unknowns
Planning	Propose windows, staging, baselines, additional checks for the exposed services; select the matching procedure from the catalogue	Traffic baselines, business calendar, catalogue, service model	Cannot create a new executable procedure without review; proposes, does not schedule
Readiness	Check, immediately before the window, that the preconditions still hold: health, redundancy, drift against the inventory, open incidents, access, backups, procedure version	Live state, inventory, incidents, backup systems	Cannot clear its own findings; a failed readiness check is a stop, not a warning
Execution assistant	Interpret checkpoint results against stop rules; explain deviations; recommend continue, hold or roll back	Live telemetry, MOP, baseline, stop rules	Cannot issue commands; cannot override a stop rule; the orchestrator executes only catalogued actions
Post-change assurance	Detect deviations on exposed services; attribute with evidence; recommend rollback or closure; feed the learning loop	Service KPIs, baseline, control groups, dependency graph, concurrent events	Cannot trigger rollback above the autonomy level authorized for that change type; must state evidence strength
Learning	Review closed changes, overruns, false stops and missed impacts; propose revisions to procedures, pre-checks, thresholds and risk features	Evidence store, change and incident history, procedure catalogue	Cannot publish a revised procedure; it proposes into the same review pipeline as a human author

Three architectural rules keep five agents from producing five incompatible decisions. First, one state machine per change, owned by the governance layer: the change’s status, approvals, checkpoints and pending actions live in one place, and agents read and annotate it rather than each maintaining its own view. Second, one policy engine: risk thresholds, authorization gates, stop rules and rollback policy are evaluated by a deterministic component that every agent consults and none can bypass. Third, a catalogue of allowed actions: the orchestrator executes procedures and steps that have been reviewed and versioned, and an agent’s output is a selection from that catalogue — never a freshly generated command. Tool-access protocols that let agents query inventories, calendars and telemetry are an access mechanism, not a substitute for the inventory, the policy engine or the orchestrator. The standards are converging on the same rules: ETSI’s 2026 study of agents in autonomous networks classifies supervised autonomous agents as those that “require operator verification, adjustment, or explicit approval before critical actions” and uses a network change agent as one of its examples, and its agent-based architecture specification makes operation authorization and auditability first-class principles (ETSI GR ZSM 020; ETSI GS ZSM 022).

What machine learning does well here: risk scoring, anomaly detection and attribution

Change risk prediction is the most mature application, and it works because change records are a labelled dataset. Every closed change carries features — type, platform, elements, time, requester, executor, MOP version, concurrency at the time — and a label: succeeded, failed, caused an incident, was rolled back. Enterprise service-management platforms have shipped predictive risk scoring on exactly this basis for several years, and operators with a few years of structured change history can train better models on their own data than any vendor can ship. The model’s value is not the score; it is the ranking of factors behind the score, which tells the approver what to look at and tells the programme which change types to industrialize first.

Post-change anomaly detection is the second, and it borrows directly from service assurance. Baselines with seasonality, change-point detection methods that notice small sustained shifts rather than only threshold breaches, and comparison against control groups — the equivalent elements that were not changed tonight — turn “the KPIs look fine” into a statistical statement with a false-alarm rate. The same machinery that assurance uses to detect a slow degradation on a core network function is what change verification uses to decide whether the degradation started with the change; the two processes should share it rather than each buying it.

One design decision inside this layer is worth stating explicitly, because getting it wrong adds minutes to every detection: not every deviation has to be persisted before it can be analysed. The reflex to land all telemetry in a database and then query it is appropriate for forensic analysis, audit, trend reporting and model training, and it is the wrong path for a decision that has to be taken between two stages of a change. Stream processing over metrics and events produces a detection in near real time; the historical store serves the investigation afterwards. Separating the fast path from the persistence path is what allows a stop rule to fire before a degradation becomes an incident, and it also keeps the cost of the fast path proportionate, because that path only needs the handful of indicators the procedure declared it would watch. Nor does every detection need a model: to notice that an interface has started dropping packets, a well-designed deterministic rule is faster, more explainable and more reliable than an agent reasoning over thousands of samples. Artificial intelligence earns its place after the detection, when several signals have to be combined, dependencies interpreted, causation distinguished from coincidence and an action recommended.

Attribution is where graph methods earn their place. Given a deviation on a service and a set of candidate causes — tonight’s changes, open incidents, traffic events — the dependency graph provides topological distance, the change record provides temporal distance, and the history provides the prior probability that this change type produces this symptom. Combined, they produce the evidence statement that section 5 asked for: not “the change caused it” but “the deviation is two hops from the changed element, started eleven minutes after step six, matches a known failure mode of this software version, and no competing event explains it”. That is a statement an engineer can act on at three in the morning and a post-implementation review can audit a week later.

What language models do well here: reading, reviewing, explaining and drafting

The MOP review is the application where language models have the clearest case, because the input is text and the failure mode is textual. A procedure whose rollback section references a step that no longer exists; a pre-check that tests the wrong interface because the template was copied from another site; a command that is valid on the previous software version and deprecated on the target; a dependency listed in the identification section and absent from the preconditions. These are the inconsistencies that peer review is supposed to catch and that tired reviewers miss, and a model that has read the operator’s whole MOP catalogue and the vendor’s documentation can flag them in seconds. The output is a list of findings for the reviewer, not a corrected document, and the distinction is what keeps the human accountable.

Drafting from history is the second application, and it has to be governed like code generation rather than like writing. A model that has seen three hundred successful executions of a platform upgrade can draft the structured procedure for the three-hundred-and-first, parameterized for the target elements, with the pre-checks and the rollback that worked before. The draft enters the same review and version-control pipeline as a human-written procedure; it does not go to production because it was generated. The gain is in the long tail: procedures that nobody had time to structure get structured, and the catalogue grows faster than the engineering team could write it.

Explanation is the third, and it is the one that changes the approver’s behaviour. A risk score of 72 does not change a decision. “High risk because the protection partner of two of the eight elements has been in degraded state for three days, because a transport maintenance on the same shared-risk group overlaps the window by forty minutes, and because the last two executions of this procedure on this platform version overran their rollback budget” changes the decision, and it changes it toward the right answer. The language model’s role is to turn the deterministic engine’s factors into a paragraph an accountable person can read, question and sign. Service-management platforms already ship this as a named capability — a generated risk explanation attached to the change request — and its value depends entirely on whether the factors behind it come from a real impact engine or from the form’s own fields (ServiceNow, Now Assist ITSM skills).

Three levels of AI autonomy, which are not the same as the execution modes

The execution modes of section 7 describe who runs the steps. The autonomy levels here describe how much decision authority the intelligence layer holds, and the two are assigned independently. A change can be executed entirely by machine with no model involved anywhere, and a change executed by hand can be prepared and diagnosed by agents throughout. Conflating them is how programmes end up believing that automation requires AI and that AI implies automation.

Level	How it works	Where it belongs
Assisted	The intelligence layer analyses, prepares and recommends; a person decides and the execution follows the normal path	Complex, rare or poorly understood changes, and any change type on its first executions
Supervised	The layer recommends or selects a catalogued procedure; execution follows policy and approvals, and a person can stop it at any checkpoint	Medium-risk changes and mature automations
Bounded autonomous	The system decides and executes within pre-authorized limits, with stop rules, audit and a demonstrated recovery	Repetitive low-risk changes whose false-stop and false-pass rates have been measured

The practical rule that follows is worth saying plainly, because it contradicts the way these programmes are usually pitched. A routine operation that is fully automated without a language model anywhere in its path is not operationally less advanced than one wrapped in agents; it is frequently more advanced, because its behaviour is reproducible and its failure modes are known. The division of labour that holds up is that AI interprets uncertainty and deterministic procedures execute precisely what is already understood. Everything in this section is an argument about which of those two a given decision actually is.

The closed loop: when change management and service assurance become one process

The end state of this design is a closed loop that the telecom automation frameworks describe in general and that change management instantiates in a specific, bounded form. Observe the exposed services before, during and after the change; detect deviations statistically; diagnose with the dependency graph and the change record; decide within policy — continue observing, hold further stages, escalate, or recover; act through the orchestrator’s catalogued rollback; verify that recovery actually restored the service; and learn. This is the closed-loop pattern of ETSI’s zero-touch architecture and of the TM Forum autonomous networks reference architecture applied to one scenario, and the scenario is a good one to start with because it is bounded: the system knows what changed, when, and what the undo is.

The authorization to close the loop automatically is the last thing granted, not the first. Automatic rollback on a KPI breach is only safe when the rollback is reversible in the strict sense of section 4, when the KPI’s false-alarm rate has been measured, when the attribution has demonstrated precision over a meaningful sample, and when a rollback cannot itself collide with another change in progress. Until then, the loop closes through a person — presented with the evidence, the recommendation and the one-click catalogued action — and that is not a failure of ambition. It is the stage of the ladder that most changes should be on.

10. Pre-change validation and the digital twin: a ladder, not a destination

“Simulate the change on a digital twin before executing it” is the sentence that appears on every transformation roadmap and resolves, on inspection, into six different techniques with very different costs, fidelities and coverage. They are best understood as rungs on a ladder: each adds confidence and cost, each catches a class of errors the one below cannot, and none of them catches everything. The design question for a change programme is not whether to build a twin but how high up the ladder each change type needs to climb — and the answer, for most changes, is lower than the roadmap assumes.

Rungs one to three: review, static validation and formal verification

The first three rungs are cheap, fast and catch the majority of configuration-induced outages, which is why they should be mandatory for every change type before anyone budgets for a twin. Document review checks the procedure for completeness and internal consistency — the job the validation agent does at scale. Static validation checks the configuration itself: syntax against the platform version, parameters against the inventory, and the computed diff against the declared intent, so that a change that says it modifies one policy and actually modifies three is caught before the window. Formal verification goes further: it builds a mathematical model of the network’s forwarding and policy behaviour from the configurations and the routing state, and proves or disproves properties — this prefix remains reachable from these customers, this access-control change does not open this port, this routing policy does not withdraw these routes — for the configuration as it would be after the change.

Formal verification of network configuration is a mature technology that most operators still treat as research. Open-source and commercial tools build the model from vendor configurations without any device images, run in minutes on networks of thousands of devices, and answer the questions that matter for most routing, filtering and segmentation changes — differential reachability between the current and the proposed configuration, filter behaviour, routing-session compatibility (Batfish; Forward Networks; IP Fabric). The hyperscalers that operate the largest networks in the world adopted this class of tool a decade ago precisely because their post-mortems showed that most network outages were configuration changes that violated an invariant somebody could have stated in advance. Alibaba’s verification system for its wide-area network reported that it “reduced the failure rate of updates of our WAN by more than half” in its first year, and its successor reports misconfiguration-caused incidents falling from 56% to 5% of the total (Hoyan, SIGCOMM 2020; Hoyan, SIGCOMM 2025). The limitation is equally clear: the model verifies what configuration implies, not what software does. A vendor bug, a hardware fault, or a resource limit reached under load is invisible to it.

Rungs four and five: emulation and the digital twin

Emulation runs the real vendor software — virtual router images, containerized network functions — on a topology that mirrors the production segment being changed, and executes the procedure against it. It catches what formal verification cannot: the behaviour of a specific software version, the interaction between features, the upgrade path’s side effects, the timing of convergence. It is the standard practice of the large cloud operators for validating network changes before they reach production. Microsoft’s analysis of two years of its own network incidents, published with its emulation system, classified 36% as software bugs, 27% as configuration bugs and 6% as human errors — 69% in categories that faithful emulation can reproduce before deployment, against 29% hardware failures that it cannot — and the system found more than fifty bugs before they reached production (CrystalNet, SOSP 2017). Open-source container-based topologies and vendor modelling labs have brought the same technique within reach of any operator with the images and the discipline to keep the topology current (Containerlab; Cisco Modeling Labs). The cost is building and maintaining the emulated topology, licensing the images, and keeping the emulation synchronized with a production network that changes daily.

The digital twin, in the strict sense, is an emulation or model that is continuously synchronized with production state and can be driven with production-like traffic and events; ETSI’s 2024 specification defines it as a virtual replica of the communications network used for what-if scenario modelling (ETSI GS ZSM 018). That synchronization is what separates a twin from a lab: the lab tests the procedure against the network as it was designed; the twin tests it against the network as it is tonight, including the drift, the degraded redundancy and the traffic profile. For the radio access network, where behaviour depends on propagation, mobility and scheduler decisions that no configuration model captures, GPU-accelerated twins that simulate the physical layer and the protocol stack together are the current frontier, and the vendors building them are explicit that the use case is validation of software and parameter changes before field deployment (NVIDIA Aerial Omniverse Digital Twin; Nokia RAN Digital Twin).

The economics of twins are unforgiving, and the honest planning assumption is that a full-fidelity twin of an operator’s whole network is neither achievable nor necessary. Fidelity is expensive at every layer — images, licences, compute, the synchronization pipeline — and the value is concentrated in a few change types: core network software upgrades, major routing or transport migrations, radio software and parameter changes with wide blast radius. A twin scoped to those types, synchronized from the same discovery pipeline that keeps the inventory true, is a credible three-year project. A twin of everything is a slide.

Rung six: the canary in production, and what no twin can see

The highest rung is also the one the hyperscalers trust most: a staged execution in production, on one element or one region, measured and reversible. It is the only validation that includes the hardware, the vendor software as deployed, the real traffic and the real dependencies, including the ones nobody modelled. It is also the rung that the recent cloud outages skipped — a change propagated globally before any canary could report — and the one that regulators now describe, in their guidance to operators, in terms of staged deployment and the ability to halt. Every rung below it reduces the probability that the canary fails; none of them replaces it.

Four things stay invisible to every twin, and they should be written into the risk model rather than assumed away:

• Hardware faults — the line card that fails on reload, the optical module that was marginal, the power supply that trips under the inrush of a restart.
• Vendor software defects that only manifest at production scale, under production timing, or on a specific hardware revision the twin does not have.
• Unmodelled dependencies — the service that rides on the element and is not in the inventory, which the twin, built from the inventory, does not know about either.
• A stale synchronization — a twin that was true yesterday validates against yesterday’s network, and reports confidence it does not have.

The practical sequence follows from the costs. Make static validation and formal verification mandatory for every configuration change, because they are cheap and catch most of the historical outage causes. Build emulation for the platform families whose upgrades are frequent and consequential. Scope a synchronized twin to the three or four change types whose blast radius justifies it. And make staged, measured, reversible execution the default for everything, because it is the one control that works on the failure modes nobody predicted.

11. What operators, hyperscalers and vendors have actually shown

The public record on automated and AI-assisted change management is thinner than the conference agendas suggest, and it is worth being precise about what kind of evidence each case provides. Three categories matter: changes that operators made under regulatory pressure after an outage, which are verified by the regulator; production deployments with quantified change outcomes, which are rare; and pilots, catalysts and vendor claims, which describe the direction of travel but not its results. Mixing the three is how a programme ends up citing a slide as a benchmark.

What the operators that failed changed afterwards

The most reliable evidence about which controls matter comes from the operators that were forced to add them. Within 48 hours of its February 2024 outage, AT&T scanned its network for elements lacking adequate controls and, by the time of the regulator’s report, had “adopted procedures to ensure that maintenance work cannot take place without confirmation that required peer reviews have been completed” — the authorization gate of section 4, enforced by the system rather than by the calendar (FCC, July 2024). Rogers replaced the risk-assessment algorithm that had downgraded the sixth phase of its core upgrade from high to low risk after five successful phases, added an enhanced equipment-introduction process, router overload safeguards, a physically and logically separate management network, and what the regulator’s report describes as AI-based predictive simulation capabilities for testing changes; the regulator states that all recommendations were implemented (CRTC, 2024).

The Japanese cases produced the most explicit procedural remediation. KDDI attributed its 61-hour outage to “insufficient work preparation” — “management rules, confirmation items and the way of approval” — and within a month had revised its work and project approval procedures, made risk analysis mandatory for every scheduled maintenance, deployed congestion-detection tooling and rewritten its congestion-recovery procedures (KDDI, July 2022). NTT Docomo, after the rollback of its IoT migration produced the signalling storm that took its network down for most of a day, committed to separating IoT registration from the main subscriber systems — a blast-radius reduction, decided after the fact, that an impact analysis would have recommended before it. The Australian operator whose 2025 emergency-call outage opened this article accepted all 21 recommendations of its independent review, which centred on procedure selection, risk classification, the composition of pre-change meetings and the treatment of alerts during a change (Schott review, Dec 2025).

Production cases with measured change outcomes

Only a handful of operator cases quantify the effect of automation on change outcomes specifically, and they are worth reading closely because they map directly onto the ladder of section 10. The most detailed is a digital-twin deployment with China Mobile’s Henan subsidiary, presented as a TM Forum Catalyst in 2025: a twin built on the vendor’s network digital map ingests live data and emulates proposed configuration changes, flagging routing anomalies and dangling access-control entries before production. The reported results are configuration validation 20 times faster than lab methods, average change completion in under four hours against two to three days previously, 6,000 network elements simulated on a single virtual machine with simulations under ten minutes, and “network change faults from human error: zero” over the reporting period (TM Forum Catalyst C25.0.828; TM Forum Inform). The figures are operator- and vendor-reported within a catalyst, not independently audited, and they describe the IP domain; but they are the clearest published demonstration that rung five of the ladder works when the twin is scoped to one domain and fed by live data.

Rakuten Mobile’s operations platform is the second quantified case, and the one with the longest production history. Its vendor arm reported in 2022 that the assurance and operations suite deployed across more than 270,000 cells with a 250-person operations team produced up to a 70% decrease in configuration mistakes and up to a 40% reduction in the time spent on monitoring, management and network change management, with 30% fewer open trouble tickets (Rakuten Symphony, Sept 2022). The caveat is structural: the vendor and the operator are the same group, and the network was built greenfield around the automation rather than retrofitted. The result is real; its transferability to a brownfield, multi-vendor operator is the open question.

Swisscom provides the most instructive end-to-end example, because it started from a real change-induced outage and built the agentic workflow described in section 9 around it. A routine configuration change intended to optimize traffic routing passed the operator’s physical lab and then caused a forwarding loop in production, through a missing route metric and a second-order effect on a dependent service. A four-month proof of concept with Cisco’s Outshift group built a network digital map — a knowledge graph assembled from the orchestrator, the inventory and telemetry — and a network digital twin combining graph-based simulation with formal verification and emulation. In the resulting workflow an engineer submits the change in the service-management tool in natural language; an assistant agent parses the intent; an impact-assessment agent predicts the blast radius; a test-planner agent writes targeted tests; a test-executor agent forks a production snapshot, applies the candidate configuration in the twin, runs formal verification and returns a verdict, which is attached to the ticket. The original outage was reproduced and prevented; the business benefit is stated qualitatively (Outshift by Cisco, Swisscom case study, 2025). Separately, the operator reports an antenna-configuration rApp running in production “with zero execution failures”, automating radio changes that delivered a 13% 5G downlink throughput gain and a 51% reduction in voice drop rate in the affected cells (Ericsson, Sept 2026), and an OSS decomposition into about thirty autonomous domains with per-domain continuous delivery that cut the time from code-ready to mass rollout in the IP domain from nine to twelve months to six weeks or less (Appledore Research for Netcracker, Oct 2025).

The large North American and European operators describe direction more than results, and the distinction matters. Verizon reports that its closed-loop automation platforms executed more than 70 million actions autonomously in 2025, including network configuration changes and element resets, that a master agent spins up specialized sub-agents to cut diagnostics from hours to under two minutes, and that it is applying agentic AI to planned configuration changes in a 60,000-site virtualized radio network — a volume figure, with no change-failure or incident metric disclosed (Verizon, June 2026). Deutsche Telekom’s radio “guardian” agent, built with Google Cloud and reported live in November 2025, scans for events, estimates capacity impact, recommends and “executes approved changes” with documentation, compressing an hour-long process to minutes (SDxCentral, Nov 2025). AT&T has deployed a generative-AI and ray-tracing digital twin of its mobile network that maps outage impact across hundreds of kilometres in about fifteen minutes and recommends or executes reconfiguration, with engineers retaining final authority on critical changes (Telco Magazine, Oct 2025), and workflow agents for engineers that gather change logs before opening tickets, with required human checkpoints (SDxCentral, Nov 2025). Orange’s automation plan is explicitly centred on “everything related to change” — a network integration factory with continuous-delivery pipelines and automated testing before production — and its first autonomous-network use cases for 2025 were change automation, a digital twin and a generative NOC assistant (Telco Titans, Dec 2024). Vodafone’s published work with Google Cloud lists configuration assistance, generated design documentation and digital twins for planning among more than a hundred identified use cases, in the future tense (Google Cloud, Nov 2024).

The orchestration-layer cases, and what they do and do not prove

A separate group of published cases is worth reading for the architecture of section 8 rather than for its results, because it is the clearest public evidence of operators putting an orchestration layer between their service-management platform and their domain controllers. These are vendor customer stories, with the reporting bias that implies, and none of them is an independent audit. What they document usefully is the division of responsibilities and the sequence of adoption.

Virgin Media O2, a UK operator whose consumer broadband, television and telephony services reach more than 46 million customers, is the cleanest example of the two-layer split. The published case describes the automation of DOCSIS service group provisioning — the configuration that brings a group of cable broadband subscribers into service — a task that previously required more than 300 lines of configuration and multiple manual touchpoints across different roles. The architecture puts an orchestration platform above a model-driven network orchestrator: the orchestration layer holds the workflow and the adapters, the model-driven orchestrator holds the device configuration, and the result is that design engineers define the parameters and the flow, back-office teams prepare the work, and field engineers execute it through self-service rather than through a coordination chain (Itential customer stories). Two caveats matter, and the case supports both. It documents provisioning, not the operator’s portfolio of planned works, and it is not evidence that planned maintenance there runs this way. And provisioning is the easier half of the problem: a new service group has no live traffic to protect, which is exactly what makes a planned change on an existing one harder than this case describes.

Lumen Technologies is the more instructive case for change management specifically, because it documents a sequence rather than a single use case. The published account describes an orchestration layer that executes under policy, an analytics platform that consolidates signals and proposes remediation, and a service-management platform as the front door for self-service requests, with atomic read-only actions — diagnostics, interface checks, route lookups — composed into reusable runbooks that carry pre-checks, post-checks and rollback by design. Every workflow, whether a person or an agent starts it, passes through the same design review, naming and adapter checks and role-based access controls, and the continuous-delivery path for the platform itself moved from three-hour manual maintenance windows in 2023 to automated zero-downtime deployments in 2024. The reported figures are 350 or more workflows live in production as of late 2025, raw alerting collapsed from more than a billion signals to roughly 57,000 actionable incidents, more than a thousand workflows identified as automation candidates with around 700 on a path to autonomous execution, and a stated goal — not a result — of 80% machine-to-machine operations (Itential, Lumen customer story). The sentence in that account that belongs in every change programme’s charter concerns how autonomy is granted: prove reliability in context — device family, region, time window — then remove the human approval for that slice while keeping audit and rollback intact. That is the execution-mode ladder of section 7, earned per slice rather than declared per programme.

Colt Technology Services is the third case and the one closest to a multinational business-services operator’s problem. The published account describes consolidating scripts that lived on individual engineers’ laptops into callable building blocks on a single governed platform across three continents, integrating address management, configuration repositories and configuration management, with service rollout timelines moving from a range of six months to two years down to weeks or months (Itential, Colt customer story). Its relevance to change management is indirect but real: the organizational change that made it work was reducing the number of places a procedure could live to one.

What this group proves, stated conservatively, is that the orchestration layer is a real and deployable architecture in large operators, and that its adoption sequence is consistent across them: read-only primitives first, composed procedures second, governance applied uniformly to human and machine callers, and autonomy granted per slice on measured evidence. What it does not prove is any claim about change-related incident rates, because none of these cases publishes a change failure rate before and after. The vendor-level claims in this category — fewer change-related incidents, fewer manual steps, shorter upgrade cycles — are attributed to named customers, are not independently verified and come mostly from outside telecom (Itential). An operator evaluating this category should ask for the change failure rate, not for the workflow count.

The agentic governance patterns now being standardized

The 2025 and 2026 TM Forum catalysts are where the guardrails of section 9 are being written down, and three of them are directly about change. A 2026 project championed by BT Group, Orange and two other operators defines an “intent-to-operate” framework unifying service activation and network change management, with “a policy-first approach for change management [that] ensures only compliant, low-risk configurations are approved for execution” and closed-loop rollback (TM Forum Catalyst C26.0.929). SK Telecom’s 2026 framework for telecom agentic AI evaluates every agent action against a policy engine, makes a human confirmation field “a hard gate” before any write, and keeps an immutable audit of the policy decision, the agent, the tool, the parameter hash and the outcome (TM Forum Inform, July 2026). The generative-AI toolkit catalyst with du, PLDT, DNB and BT validates each agent action against policy guardrails before execution through the standard ordering and activation APIs, and reports fault triage up to 85% faster and early operating-cost savings above 20% (TM Forum Inform, June 2025). None of these is a production result for change management; all of them are the industry converging on the same architecture — policy engine, hard gate, catalogue, audit — that the outages of section 1 argue for.

The market’s self-assessment is sober. An Omdia survey of transport-network operators in early 2026 found 70% at Level 2 or below on the autonomy scale and 23% at Level 3; 64% plan a transport digital twin within a year, 47% use AI in production, and 45% name accuracy and reliability as their top concern about agentic AI (Omdia for Cisco and Ciena, Feb 2026). The concern is the right one, and it is the reason the ladder of section 10 climbs from formal verification upward rather than starting at the top.

The hyperscalers: the reference bar for change safety

The companies that operate the largest networks in the world have published their change-safety engineering in more detail than any telecom operator, and their practices are the reference bar. Google’s analysis of more than a hundred post-mortems from its production networks found that a large number of failures happen while a network management operation is in progress — the example given is a misconfigured wildcard that drained hundreds of devices instead of two — and derived design principles that include defence in depth, consistency across the data, control and management planes, failing open, and canarying every change (Govindan et al., SIGCOMM 2016). Meta’s 2024 account of change management across hundreds of thousands of devices in 25 data centres describes binary and bundle qualification on realistic production canaries, phased rollouts by device role and hardware with per-phase failure thresholds that halt automatically above 5% health-check failures, pre-deployment device and scope health checks, before-and-after snapshot comparisons of routes, BGP sessions and interfaces, emulation-based verification of routing policy, and automatic pause of pushes on network loss (Meta, @Scale 2024); a 2026 paper adds that every code and configuration change entering production passes through a health-check gate as a mandatory step, with tiered and phased rollouts and automatic rollback, and names the October 2021 outage as the motivation (arXiv, Aug 2026).

Microsoft’s CrystalNet is the canonical emulation case. Presented in 2017, it emulates the production network with real device software at scale to validate configuration and firmware changes and entire methods of procedure, including their rollbacks, before they are executed; the published result is a regional backbone migration completed with zero user-impacting incidents (Microsoft Research; CrystalNet, SOSP 2017). Azure’s networking team subsequently described a global network emulator, a real-time operation checker that simulates planned maintenance and issues approval tokens before a change is allowed to proceed, staged rollouts from integration and canary regions, and declarative zero-touch changes with automated rollback on health-signal failure (Microsoft Azure, Nov 2020). That the same company suffered a global configuration-induced outage in October 2025 is not evidence against these practices; the post-incident review shows precisely which gap in them — validation across control-plane versions, an overwritable rollback point — the failure found, and the remediation closes it.

AWS’s response to its October 2025 outage illustrates the governance of automation itself. The outage was not a human change but a latent race condition between two instances of a DNS automation that produced an empty record for a critical regional endpoint. The company’s response was to disable that automation worldwide pending a fix, add protections against applying incorrect plans, introduce velocity controls limiting how much capacity its load balancers can remove on failover, and build a recovery test suite (AWS post-event summary, Oct 2025). The lesson for an operator granting autonomy to a change loop is direct: an automation that can act on production needs the same stop rules, velocity limits and kill switch that a human change does, because its failure mode is faster.

Vendor offerings: what each one actually does for a change

The vendor landscape maps onto the lifecycle and the ladder, and it is more useful to place each product on them than to compare them head to head. No product covers the whole lifecycle; most cover one or two stages well, and the integration between them is the operator’s work.

Product family	What it does for a change	Lifecycle stages and ladder rungs	Evidence available
Model-driven network orchestrators (Cisco NSO and Crosswork Change Automation, Nokia NSP, Juniper Apstra)	Procedures codified as executable plays with dry run, single-step or continuous execution, pre- and post-maintenance verification, transactional commit, selective rollback and audit trail; Apstra pre-validates every change against intent and offers point-in-time rollback	MOP, execution, verification; rungs 2 and 6	Product documentation; Crosswork data sheet describes KPI-triggered remediation “with or without operator approval” (Cisco)
Network verification and digital-map platforms (Forward Networks, IP Fabric, NetBrain)	Formal model of forwarding and policy from configurations and state; pre-change path and blast-radius simulation; pre/post snapshots; golden-configuration drift detection; ticket enrichment	Impact, pre-checks, verification; rung 3	Vendor claims; telecom references anonymized; NetBrain’s “triple defence” pre/during/post-change model (NetBrain, Feb 2025)
Domain controllers with change simulation (Huawei iMaster NCE, Nokia EDA)	Twin of protocol state, routing, service paths and traffic to simulate a change before it is applied; containerized simulators to test changes; state rewind	Pre-validation, execution; rungs 4 and 5	China Mobile Henan catalyst results for Huawei (TM Forum); Nokia documentation (Nokia EDA)
RAN automation platforms and rApps (Ericsson EIAP, Nokia MantaRay)	Radio parameter and configuration changes as governed automated actions with mass-change verification; agentic rApps proposing and executing optimizations	Execution, verification; rung 6 in the radio domain	Swisscom rApp “zero execution failures” (Ericsson); AT&T, Swisscom, Telstra and Vodafone named as EIAP users (Ericsson, June 2026)
RAN digital twins (NVIDIA Aerial Omniverse Digital Twin, Samsung research)	Physical-layer and protocol-stack simulation to validate software updates and parameter changes against a virtual copy of the deployment; continuous-delivery pipeline for RAN software	Pre-validation; rung 5 in the radio domain	Vendor and research publications; no named operator results (NVIDIA, Dec 2025)
Service-management platforms (ServiceNow, BMC)	Change record, types, approvals, calendar, collision detection, risk scoring from history, generative assistance for change summaries and risk explanation	Intake, collisions, authorization, closure; rung 1	Product documentation; quantified customer claims circulate without attribution and should be treated as unverified
General automation platforms (Ansible, pipelines, GitOps tooling)	Check mode, diff, idempotent execution across heterogeneous infrastructure; version control and review workflow for procedures as code	MOP, execution; rung 2	Mature, widely used; results are operator-specific

What the evidence supports, stated plainly, is narrower than the marketing and broader than the scepticism. Executable procedures with dry run, transactional execution and rollback are mature and proven. Formal verification of configuration is mature and underused. Emulation of whole procedures works at hyperscaler scale and in single-domain telecom deployments with quantified results. Agentic review, impact assessment and test generation have been demonstrated end to end in at least one operator proof of concept that reproduced and prevented a real outage. Autonomous execution of changes with published quality metrics exists in the radio domain for bounded parameter changes and in one greenfield operator. Everything beyond that — multi-domain twins, autonomous rollback, agents owning the change decision — is a roadmap, and the operators with the most credible programmes are the ones that say so.

12. Risks, limits and the parts of the story that are hype

A change programme can fail in ways that look like success for a year, and the most important of them is the one where the metrics improve because the process started blocking more. A change failure rate that falls while the number of changes rejected, deferred or reclassified rises is not a safer network; it is a slower one, with the same risk moved into a backlog of overdue upgrades and a growing population of emergency changes that skip the controls. The honest scorecard pairs every safety metric with a throughput metric and reports both.

Eight ways the programme goes wrong

1. Agents reviewing documents and calling it automation. A language model that reads the change request and the MOP and produces findings is useful. If the execution is still a technician with a terminal and a PDF, the programme has automated the paperwork and left the risk where it was. The middle column of the table in section 7 — orchestration, assertions, staging, tested rollback — is where the safety comes from, and it is the column that agentic demonstrations skip.
2. Automating on top of a stale inventory. Every automated impact assessment inherits the inventory’s errors at machine speed and with machine confidence. A programme that does not measure inventory accuracy per domain before trusting automated impact analysis will discover the measurement during an outage.
3. Letting a model generate commands. A language model that writes configuration into production, even with a human “approving” it, has converted the reviewer into a rubber stamp for text the reviewer did not write and cannot fully verify under time pressure. Generated procedures enter the catalogue through review and version control, or not at all.
4. Granting automatic rollback before measuring attribution. An automated rollback triggered by a deviation that the change did not cause wastes the window, delays the real diagnosis, and — if the rollback collides with another change — creates the outage it was meant to prevent. Rollback autonomy is earned per change type with a measured false-positive rate.
5. Building the twin before the ladder. A synchronized digital twin is the most expensive rung and depends on the inventory, the discovery pipeline and the executable procedures that the lower rungs require anyway. Started first, it becomes a demonstration environment that is never quite synchronized and never quite trusted.
6. Uniform gating. Routing every change through the same board, the same forms and the same lead time guarantees that teams will find the path of least resistance — usually “emergency” — and that the board will spend its attention on the changes that least need it.
7. Treating the regulator’s guidance as a compliance exercise. The resilience and security codes that now ask operators for tested changes, staged deployment, rollback capability and segregation of duties are describing the controls that would have prevented the outages the regulators investigated. An operator that implements them as evidence for an audit, rather than as operating practice, will produce the audit trail of the next outage in excellent order.
8. Buying the orchestration layer and calling it the process. A platform that executes procedures across domains is a necessary component and is not a change capability. It does not know what depends on the element, it does not optimize the window, it does not detect a service degradation and it does not learn, and an operator that treats the purchase as the programme will have industrialized the execution of procedures whose design nobody improved. The failure mode is specific and recognizable: a steadily rising count of automated workflows alongside a change failure rate that has not moved.

What is genuinely uncertain

Three things remain open, and a credible programme says so. The first is the real precision of language-model procedure review on an operator’s own catalogue: published figures come from vendors and pilots, and the only number that matters is the one measured on the operator’s MOPs against its own reviewers’ findings. The second is the fidelity ceiling of digital twins for multi-vendor, multi-domain changes: the published results are from single-domain or single-vendor environments, and the interaction effects that cause the worst outages are exactly the ones that cross those boundaries. The third is the governance of autonomy itself: no regulator has yet said, in binding terms, what evidence an operator must hold before a system is allowed to execute and reverse changes on critical infrastructure without a person in the loop, and the first serious outage caused by an autonomous change loop will write that rule for everyone.

13. The implementation sequence, the metrics and the decision rights

The sequence that survives contact with an operator’s existing tools, inventory and culture has four waves, each with its own exit evidence, and it does not start with agents. It starts with the visibility and the data that everything else consumes, builds the executable procedures and the verification that produce safety, industrializes execution, and only then raises the autonomy of specific change types on measured evidence.

Wave	Capabilities	Exit evidence	Typical duration
1. Control and visibility	Structured intake, queryable calendar, collision queries, inventory accuracy measured per domain, change failure rate baselined	Share of complete requests at first submission; collisions detected before approval; inventory accuracy figures per domain with owners	Months 1 to 4
2. Verification and structured procedures	Ten-section MOP template for all types; static validation and formal verification for configuration changes; pre-checks as assertions; baseline capture; post-checks against baseline; rollback classification	Pre-check and post-check coverage by change type; changes stopped by pre-checks; incidents attributed to changes detected by post-checks rather than by customers	Months 3 to 9
3. Industrialized execution	Catalogue of executable procedures for the high-volume types; orchestrator-driven staged execution with checkpoints; tested rollback; inventory write-back at closure; risk scoring from history	Share of changes executed from the catalogue; execution time and rollback time per type; change failure rate by execution mode	Months 6 to 15
4. Autonomy by scenario	Supervised automatic execution for proven types; post-change assurance with attribution; closed loop with policy-bounded rollback; emulation and scoped twin for the consequential types; learning loop into MOPs and risk model	Change types promoted per execution mode with measured false-stop and false-pass rates; autonomy level per type documented and audited	Months 12 to 30

Which change types to start with

Three families of change types make the first year productive, and the glamorous ones are not among them. Frequent, low-risk changes — parameter changes, standard capacity additions, certificate rotations — are where executable procedures and supervised execution deliver visible automation fast. Frequent changes with real service exposure — platform software upgrades, routing policy changes, firewall and security changes — are where pre-checks, dependency analysis and post-change verification prove their value, because the baseline failure rate is high enough to measure an improvement. Historically problematic change types, identified from the incident records, are where the programme demonstrates that preventive analysis catches what the old process missed. The rare, complex, cross-domain migrations that make the best slides are the worst place to start: they cannot be normalized, they cannot be measured on a sample, and a failure discredits the programme.

Ordered by the ratio of value to difficulty, the portfolio of candidate change types is reasonably consistent across operators, and the order is close to the inverse of the order in which they tend to be attempted.

Priority	Change type	Principal value	Difficulty
Very high	Software and firmware upgrades of network elements	Productivity, fewer errors, standardization	Medium
Very high	Repetitive IP configuration changes	Automation and traceability	Medium
Very high	Pre-checks and post-checks for critical work	Fewer incidents, demonstrable assurance	Medium to high
High	Controlled traffic migrations	Reduced service impact	High
High	Window management and collision resolution	Lower accumulated risk across concurrent work	High
High	Correlating degradations with work in progress	Fewer change-induced incidents reaching customers	High
Medium to high	Coordinated changes across IP, transport and cloud	Fewer waits and less manual coordination	High
Medium	Assisted drafting of procedures from history	Less engineering effort on the long tail	Medium
Evolutionary	Closed-loop change execution	Prevention, decision and recovery automated	Very high

The metrics, paired so that they cannot be gamed

The first risk in measuring this programme is celebrating the wrong number. Workflows built, procedures converted and tickets automated measure activity, not outcome, and a dashboard made of them will look healthy through the eighteen months in which nothing improves. Four dimensions have to move together — productivity, reliability, customer impact and maturity — and each metric in the first column below is paired with one in the second precisely because any of them can be improved on its own by making the operation worse somewhere else.

Metric	What it measures	Paired with
Change failure rate	Share of changes that cause an incident, a rollback or a failed post-check (the DORA definition, applied to network changes by type and by execution mode)	Change throughput and lead time, so that a falling failure rate from blocking is visible
Incidents attributed to changes	Real operational impact, with the attribution evidence recorded	Incidents with change impact missed by post-checks and found by customers
Complete at first submission	Quality of intake	Requests returned, and time lost to returns
Pre-check and post-check coverage	Share of changes by type with assertions executed and results stored	False stops (changes halted by a check that was wrong) and false passes
Catalogue coverage	Share of change volume executed from versioned, executable procedures	Share of change volume still on undocumented or e-mailed procedures
Time to prepare and authorize; time to execute and to roll back	Efficiency of the lifecycle	Emergency changes as a share of the total, as a signal that the normal path is too slow
Inventory accuracy per domain	The ceiling on impact analysis	Share of changes on elements with unmapped services
Time to detect change impact	Speed of post-change verification	Attribution precision over a sample of reviewed cases

The business case, and the two ways it is usually overstated

The productivity half of the case is easy to compute and easy to oversell. Take an operator running 40,000 planned works a year, automate half of them, save 45 minutes of preparation and coordination on each, and value internal capacity at 60 euros an hour: that is 15,000 hours a year, or about 900,000 euros of capacity released. Those numbers are illustrative rather than researched, and they are capacity released rather than budget saved, which is the first way the case is overstated. The hours do not leave the cost base unless the organization decides they should; what they buy is the ability to execute more change with the same team, which is usually what the operator actually wants. The calculation also excludes licences, integration, maintenance and the cost of the transformation itself, and a case that omits those is a slide rather than a case.

The reliability half is larger, harder to evidence and the reason the programme is worth doing. Preventing one major incident during a change to the core, the backbone or a service platform can be worth more than a year of released hours, and the public record of section 1 puts numbers on the upper tail: customer credits in the hundreds of millions, regulatory penalties in the tens of millions, and remediation programmes in the billions. An operator cannot claim that upper tail in a business case on the strength of an analogy, but it can do two things that are defensible. It can price its own history — the change-induced incidents of the last three years, their duration, the customers affected, the credits paid and the service-level penalties incurred — and it can measure, in the pilots, how many of those historical incidents the new controls would have caught. The second way the case is overstated is double counting: productivity, incident reduction, availability, service-level compliance and faster deployment overlap, and summing all five as independent benefits produces a number nobody in finance will accept twice.

Who owns what

The technology is usually less contested than the decision rights, and a programme that does not settle them early settles them during its first serious incident. The split that works separates the governance of the process from the ownership of the procedures, the execution from the verification, and the platform from all of them:

Function	Owns	Does not own
Change management	The process, its policies and types, the calendar, the authorization model, the metrics	The content of procedures; the verdict on service impact
Domain engineering	The MOP catalogue for its platforms: definition, validation, versioning, pre-checks, rollback; technical and functional verification	Authorization of its own changes above standard; service-level success
Operations	Execution, supervision, checkpoint decisions within stop rules, response to exceptions	Modifying an approved procedure in the window; declaring service success
Service assurance	Service KPIs and baselines, post-change detection and attribution, evidence of recovery, the verdict on service and business success	Execution; the procedure catalogue
Platforms and IT	Workflow, integrations, orchestrators, the inventory platform, access control, the evidence store, the agents’ tooling	Process policy; procedure content; autonomy decisions
Security	Segregation of duties, privileged access to execution systems, audit, and the limits on autonomous action	Operational decisions inside the window

Underneath that matrix sit three ownerships that should never collapse into one. The process owner is accountable for the change being prepared, authorized, executed and closed according to policy, with measurable outcomes. The technical owner is accountable for how the infrastructure is modified, what conditions make the change safe and how it recovers from a failure. The service assurance owner is accountable for how it is verified that the result has not compromised the customer experience, and for when a change may be declared stabilized. Separating the three prevents the only genuinely dangerous arrangement, which is the team that executed the change also being the only one entitled to declare that it went well. The caveat is equally important: three ownerships are not three organizations with three records. They share one state machine per change, or the separation has reinvented the handoffs that section 3 removed.

14. Conclusions: eight positions, stated so that they can be argued with

The first position is that change governance is the highest-return reliability investment available to an operator, and that it is systematically underfunded relative to redundancy, monitoring and incident response. The outages that reached parliaments and regulators in the last four years were caused by planned changes, executed by competent people, following processes that existed on paper. The controls that would have prevented them — independent review, lab testing, staged deployment, a tested way back, knowledge of what depended on the element — are not expensive. They are unglamorous, and they compete for attention with technologies that photograph better.

The second position is that the method of procedure is the unit of industrialization, and that converting it from a document into a versioned, executable, testable specification is the single change-management investment with the best ratio of safety to cost. The frameworks govern around the MOP and leave its content to the operator; the orchestrators that can execute it have existed for years; what is missing is the catalogue, the review discipline and the governance of which procedures may run in which mode. That is organizational work, and it is the work.

The third position is that the inventory sets the ceiling on everything built above it, and that change management is both its biggest consumer and, unless the closure step writes back, its biggest corrupter. Impact analysis, collision detection, pre-change drift checks, post-change attribution and every twin are only as good as the resource-to-service-to-customer graph they read. An operator that automates change on top of an unmeasured inventory has automated its blind spots.

The fourth position is that artificial intelligence belongs beside the critical path of a change, not on it. Statistical models for risk and anomaly detection are fast, cheap and measurable, and they can sit in the loop. Language models and agents interpret, review, explain and draft, and they are valuable in exactly those roles — but no model generates commands into production, no agent owns the state of a change, and no agent decides; a deterministic policy engine decides, and an orchestrator executes only what has been reviewed into a catalogue. That architecture is not a limitation on AI. It is what makes AI deployable on critical infrastructure.

The fifth position is that the digital twin is a ladder, and that most operators should climb the first three rungs for every change before building the fifth for any. Static validation and formal verification catch most of the historical outage causes for a fraction of the cost of a synchronized twin; emulation earns its cost on frequent, consequential platform upgrades; a twin earns its cost on a handful of change types with wide blast radius. Staged, measured, reversible execution in production remains the only validation that sees the failure modes nobody predicted, and it is the one that the recent cloud outages skipped.

The sixth position is that the destination is the convergence of change management with service assurance and network automation into one closed loop, and that the loop is closed last, per change type, on evidence. The operators that have published credible autonomy results describe the same sequence: structured data, executable procedures, measured verification, and then — for specific, bounded scenarios — the authorization to act without a person in the loop. The order matters more than the model. An operator that follows it will find, as those operators did, that the intelligence layer was the straightforward part; the hard part was making the procedures, the inventory and the evidence true enough for the intelligence to be trusted.

The seventh position is organizational, and it is the one that section 3 adds to the technical argument: change management should be redesigned around governed state transitions before its ten stages are automated. Automating the existing workflow in place accelerates the handoffs and digitizes the bottlenecks. Redesigning it keeps the controls, removes the administrative work that only existed because the systems were not integrated, lets policy decide what policy can decide, re-evaluates every approved change continuously against the live network, and assigns each change to an operating mode by its risk and its conditions on the night. The operator that does this will find that change management has stopped being a process it runs and has become a capability it engineers — and that the agents, the twin and the executable procedures were components of that capability all along.

The eighth position is architectural, and it is the one that decides whether any of the previous seven can be built: governing a change, orchestrating it and executing it are three different responsibilities, and an operator has to name an owner for each. Service-management platforms govern well and were never designed to run a twelve-step procedure across six domains. Domain controllers execute well and were never designed to own an organizational process. The layer in between — executable procedures, checks between the steps, stop rules, recovery paths, evidence, and policy enforced at the moment of execution rather than at the moment of the meeting — is the one most operators do not have, and it is the reason their methods of procedure are still documents. It is also the layer most likely to be oversold, because it is the easiest to demonstrate: a platform will execute a badly designed procedure flawlessly, over a stale inventory, and produce a complete audit trail of the resulting outage. Buy it for what it does, which is a great deal; do not expect it to supply the impact analysis, the planning, the detection or the learning, because those live in the other four layers and they are where the difference between an automated change process and a safe one is actually decided.

---

At TelcoCrux, we help operators and service providers turn change governance from a document-based ritual into an industrialized, verifiable capability: which change types to put on executable procedures first, what the inventory can and cannot support, where formal verification, emulation and a scoped twin actually pay back, and how to let AI advise the process without ever letting it own the decision. If you are designing or rescuing a change automation programme and want an independent read before the next window opens, let’s talk.