itory Images Images Recipes FIGURE 7.5 SDC design studio in ONAP. The Network Operating System Another example is to describe the workflow steps as a process in the metadata that can be used by ONAP orchestration to fulfill a customer service request. Network cloud policies are one type of metadata, and will eventually be quite numerous and support many purposes. Policies are created and managed centrally SO that all policy actions, both simple and complex, are easily visualized and understood together, and validated properly prior to use. Once validated and corrected for any conflicts, the policies are precisely distributed to the many points of use/enforcement; the decisions and actions taken by policy are distributed, but are still part of the policy component of ONAP. In this manner, policies will already be available when needed by a component, minimizing real-time requests to a central policy engine/policy decision point (PDP), or to policy distribution. This improves scalability and reduces latency. SDC and policy creation exist in close relationship. Policies are created by many user groups (e.g., service designers, security personnel, operations staff, etc.). Various techniques are used to validate newly created policies and to help identify and resolve potential conflicts with preexisting policies. Validated policies are then stored in repositories. Subsequently, policies are distributed in two ways: (1) service-related policies are initially distributed in conjunction with the distribution of recipes (created via SDC), for example, for service instantiation and (2) other policies (e.g., some security and operations policies) are unrelated to particular services, and therefore, are indepen- dently distributable. In any case, policies are updatable at any time as required. SDC employs a set of "studios" to design, certify, and distribute standardized models including the relationships within and across them. From a bottom-up view, SDC provides tools to onboard resources such as building blocks and to mak