f a particular network cloud policy may be defined at a high level to cre- ate a condition, requirement, constraint, or need that must be provided, maintained, and enforced. A policy may also be defined at a lower or "functional" level, such as a machine-readable rule or soft- ware condition/assertion, which enables actions to be taken based on a trigger or request, specific to particular selected conditions in effect at that time. This can include XACML policies, Drool policies, etc. Lower level policies may also be embodied in models such as YANG, TOSCA, etc. 7.7.1 POLICY CREATION The ONAP policy platform has a broad scope supporting infrastructure, product/services, operation automation, and security-related policy rules. These policy rules are defined by multiple stakehold- ers (network/service designers, operations, security, customers, etc.). In addition, input from various sources (SDC, policy editor, customer input, etc.) should be collected and rationalized. Therefore, a centralized policy creation environment will be used to validate policies rules, identify and resolve overlaps and conflicts, and derive policies where needed. This creation framework should be uni- versally accessible, developed, and managed as a common asset, and provides editing tools to allow users to easily create or change policy rules. Offline analysis of performance/fault/closed-loop action data are used to identify opportunities to discover new signatures and refine existing sig- natures and closed-loop operations. Policy translation/derivation functionality is also included to derive lower level policies from higher level policies. Conflict detection and mitigation are used to detect and resolve policies that may potentially cause conflicts, prior to distribution. Once validated and free of conflicts, policies are placed in an appropriate repository. Building the Network of the Future 7.7.2 POLICY DISTRIBUTION After completing initial policy creation or modification to existing policies, the policy distribu- tion framework send