ult Building the Network of the Future Policy "deployed" in ECOMP with limited Validation: Policy Offline lab env., scope and/or functionality Authoring Validation historical Policy active / operational! Safe Mode / Policy "End Guard Rails, Online of Life" Validation and Monitoring Policy fully Policy retired activated FIGURE 15.3 Policy life cycle. in modifications to a preexisting policy or new operational data or experiences may indicate that a policy needs to be modified. To mitigate risk, even a well-tested new policy will typically be deployed into the network incre- mentally. This may involve turning up the policy in a small portion of the network, and/or for a period of time having network operators validate the event detection in a control loop policy before an action is performed. Consider the example in Figure 15.4 of the simple control loop policy, which automatically restarts a VM if it is determined to be unresponsive. There is a particular signature that defines that a VM is unresponsive, and this signature could be relatively complex in its defini- tion. Thus, as the policy is first introduced into the live network, it may be executed in a "safe mode" where only the condition ("if VM unresponsive") is executed, without the automated action (reboot VM) being performed. Instead, ONAP either waits for a human operator to approve the action rec- ommended by the system before it is performed, or simply opens a ticket for manual investigation and repair when the condition is detected. An operator monitoring this new policy can validate that the conditions are being successfully detected; once the operator is satisfied with the policy operat- ing in safe mode, it can be fully operationalized SO that the actions are also automatically executed. Such a process can also be performed with control loop policies that involve multiple steps, such as that illustrated in Figure 15.5. With such a policy, each of the different conditions can be validated using the above approach before the next condition in the seq