us, service designers and operators should be ultimately responsible for designing and managing the guard rails; similarly, if a guard rail is ever "hit," the operations team should be notified and be responsible for investigating and resolving the conditions that triggered the event. Policy testing and automated validation techniques need to be complemented with an overarch- ing governance process designed to manage how policies progress through the policy life cycle. The governance process provides a gating process for determining when policies should be moved to field deployment, into and out of safe mode, and to decide when to remove policies from the ecosystem. This governance process would typically be owned by service designers and network operators. In addition to validating individual policies, we must also consider how multiple policies inter- relate. As the number of policies in the ONAP infrastructure scales up, it will become increasingly challenging to understand how different policies interact and to ensure that these policies are consis- tent. As an example, we need to be able to identify when two different policies may create potential conflict-for example, two different policies with the same priority may under the same conditions specify different actions. As a simple example, consider the two policies captured in Figure 15.7. The first policy says that ONAP should reboot a VM if its available memory drops below 20 GB; the second policy says to migrate the VM if the available memory drops below 15 GB. The two policies have overlapping conditions (when available memory <15 GB) where there are two different actions specified-reboot the VM in the first policy versus migrate the VM in the second. Which action should the system take? These policies conflict, and should not coexist in the ONAP system unless one is defined to be of higher priority than the other. ONAP uses advanced analytics to validate individual and combinations of policies before field deployment, including checking for conflicts s