 be validated-to verify that it was successfully deployed and that there were no negative side effects. Thus, checks are defined both before and after the change is executed; the results of these post-tests are compared to determine whether the change was successful or not (e.g., [MERCURY]). If the change was not successful, then the change may be rolled back, or a different mitigation action may be executed. Historically, network changes were performed using a combination of ad hoc scripts and manual intervention, with each operations team typically creating their own scripts. Systems would track change management schedules for different technologies and attempt to identify conflicts across different activities both within the same technologies and across network layers. Complex, manual "deconflicting" would then be involved in trying to deal with conflicts identified. In contrast, ONAP provides a consistent and systematic approach for change management across all network functions, thereby eliminating the need for ad hoc scripts and providing consistent pro- cess across network function technologies. Change management workflows are specified via ONAP through simple drag and drop capabilities, leveraging predefined, reusable recipes that describe the mechanisms for executing the change (software and/or configuration update) and the health checks. Changes are scheduled using sophisticated scheduling algorithms that account for activities across different network functions of the same type, across network layers and along the service path to avoid conflicts. As you can imagine, with hundreds of thousands or more network functions, complex service paths, multiple network layers, and a dynamic network, it can be extremely complicated to achieve such scheduling, necessitating sophisticated optimization algorithms and detailed and accu- rate cross-layer topologies. However, if achieved, this avoids the need to do manual deconflicting. Network Operations Finally, ONAP also automates the execution of the workflow across