-ONAP POLICY is composed of several subcomponents: the **Policy Administration Point (PAP)**, which offers interfaces for policy creation, and two types of **Policy Decision Point (PDP)**, each based on a specific rules technology. PDP-X is based on XACML technology and PDP-D is based on Drools technology. PDP-X is **stateless** and can be implemented using a resource pool of PDP-X servers. The number of servers can be grown to increase both capacity (horizontal scalability) and to increase availability. The PDP-D is **stateful**, as it utilizes Drools in its native, stateful way and transactions persist so long as the PDP-D is active. Persistent Drools sessions, state management, local and geo-redundancy have been deactivated for the initial release of ONAP POLICY and will be turned on in a future release. Additional instances of XACML/Drools engines and assigned roles/purposes may also be added in the future to provide a flexible, expandable policy capability.
-
-As illustrated in the Figure below, the POLICY components are supported by a number of interfaces and subsystems. The ONAP Portal provides a human interface for the creation, management and deployment of policies. It is a web-based system that utilizes internal APIs in the PAP.
-
-.. image:: https://wiki.onap.org/download/attachments/1015858/PolicyArchitectureDetails.png?api=v2
-
-
-The PAP provides interfaces and management of policy definitions. It utilizes the XACML database to store policy definitions, which are then distributed to the PDPs.
-
-The XACML and Drools databases are hosted in a MariaDB cluster. The XACML database is used to persist policy definitions and provide a point for PDPs to retrieve policy definitions. The XACML database also has tables used for node state management, detection of node failure and failover. As indicated above, the state management tables will only include entries for the PAP and PDP-X as the testing is not yet complete for the PDP-D.
-
-The PDP-X receives deployed policies and has interfaces to handle XACML policy transactions. These transactions are stateless and once complete, they are removed from memory. If a policy that is deployed to the PDP-X is of an operational nature it will contain Drools rules and Java executables. These artifacts are processed into Maven artifacts and pushed to the Maven repository. The PDP-D is then notified a new policy has been deployed.
-
-When the PDP-D is notified a new policy has been deployed, it downloads it from the Maven repository and assigns it to an internal controller. This controller provides the external Closed Loop interfaces to the DMaaP message bus over which events and messages are exchanged with external systems. As events or messages arrive at the PDP-D, they are assigned to the appropriate controller and a Drools session is either created or retrieved from memory. The events, messages or facts are passed to the Drools session and the rule engine is fired, resulting in a change of internal session state and possibly actions taken in response to the rule processing. Response messages and requests are passed by the controller back over the DMaaP message bus to the appropriate system. The Drools session can also have timers and autonomous events. In a future release the PDP-D will enable the node state management and session persistence in the Drools DB.
-
+ONAP POLICY is composed of several subcomponents: the **Policy Administration
+Point (PAP)**, which offers interfaces for policy creation, and two types of
+**Policy Decision Point (PDP)**, each based on a specific rules technology.
+PDP-X is based on XACML technology and PDP-D is based on Drools technology.
+PDP-X is **stateless** and can be deployed as a resource pool of PDP-X servers.
+The number of servers can be grown to increase both capacity (horizontal
+scalability) and to increase availability. The PDP-D is **stateful**, as it
+utilizes Drools in its native, stateful way and transactions persist so long as
+the PDP-D is active. Persistent Drools sessions, state management, local and
+geo-redundancy have been deactivated for the initial release of ONAP POLICY
+and can be turned on in a future release. Additional instances of XACML/Drools
+engines and assigned roles/purposes may also be added in the future to
+provide a flexible, expandable policy capability.
+
+As illustrated in the Figure below, the POLICY components are supported by a
+number of interfaces and subsystems. The ONAP Portal provides a human
+interface for the creation, management and deployment of policies. It is a
+web-based system that utilizes internal APIs in the PAP.
+
+.. image:: PolicyArchitectureDetails.png
+
+
+.. image:: PolicyArchitectureDetailsKey.png
+
+
+The PAP provides interfaces for the management of policies. It utilizes the
+XACML database to store policies, which are then distributed to the PDPs.
+
+The XACML and Drools databases are hosted in a MariaDB cluster. The XACML
+database is used to persist policies and policy dictionaries and provide a
+point for PDPs to retrieve policies. The XACML database also has tables used
+for node state management, detection of node failure and failover. As indicated
+above, the state management tables will only include entries for the PAP and
+PDP-X as the testing is not yet complete for the PDP-D.
+
+The PDP-X receives deployed policies and has interfaces to handle XACML policy
+transactions. These transactions are stateless and once complete, they are
+removed from memory. If a policy that is deployed to the PDP-X is of an
+operational nature it will contain Drools rules and Java executables. These
+artifacts are processed into Maven artifacts and pushed to the Maven
+repository. The PDP-D is then notified a new policy has been deployed.
+
+When the PDP-D is notified a new policy has been deployed, it downloads it from
+the Maven repository and assigns it to an internal controller. This controller
+provides the external Closed Loop interfaces to the DMaaP message bus over
+which events and messages are exchanged with external systems. As events or
+messages arrive at the PDP-D, they are assigned to the appropriate controller
+and a Drools session is either created or retrieved from memory. The events,
+messages or facts are passed to the Drools session and the corresponding rule
+is fired, resulting in a change of internal session state and possibly actions
+taken in response to the rule processing. Response messages and requests are
+passed by the controller back over the DMaaP message bus to the appropriate
+system. The Drools session can also have timers and autonomous events. In a
+future release the PDP-D can enable the node state management and session
+persistence in the Drools DB.
+
+Casablanca Additions to Architecture
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The Casablanca Release introduced two new applications into the Architecture:
+The Policy SDC Distribution Application and the Apex PDP Engine. These are not
+depicted in the picture above.
+
+The Policy SDC Service Distribution application connects to SDC Service
+Distribution notification flow to automatically create policies. It is
+integrated with the current API. For more details on this applications
+documentation, please see :ref:`apex-doc` for more information.
+
+The Apex PDP Engine was ingested into the platform. This integration was as is
+and did not formalize the Apex engine into the current policy API creation and
+distribution flows. For more details on the Apex PDP Engine, please see
+:ref:`policy-ssd-doc` for more information.
+
+Further integration of these components is planned for Dublin release.