# Policies

A **policy** is an operational rule defining the required approval `workflow` for the execution of a particular **intent**. It regulates user entitlements and, if properly configured, ensures that the governance is properly distributed and the system has no single point of compromise. 

In particular, **policies** regulate the approval `workflow` for the creation and update of
- **domains**,
- **users** and their related roles,
- **policies** and their related approval workflows (i.e., creating and updating **policies** is itself subject to a **policy**),
- **accounts**,
- **vaults**,
- **endpoints**,
- **transaction orders.**

**Policies** may also regulate other interactions with the system, such as the release of quarantined, incoming **transfers**.

**Policies** may be refined to cover precise use cases using the property `condition`. A `condition` can be any combination of predicates over the context parameters, which are injected into the evaluation context of the condition at runtime. Such parameters depend on the intent type and other factors. In particular, an **intent** related to a **transaction order** includes information such as the amount, destination(s) address, and source account of the order; an **intent** related to a **user** includes the roles of the user, its alias, etc. For more information about context parameters, we refer to the reference manual.

Because there may be many **policies**, multiple of which may apply to a given **intent**, **policies** are sorted according to property `rank` such that the highest rank policy to match a particular intent is selected.

**Policies** may be defined such as to regulate **intents** within the current domain, or **intents** initiated within a subdomain, or both, with property `scope`. We refer to the reference manual for more information on supervision and governance delegation.

The property `workflow` defines the approval workflow that should be satisfied for an intent to be approved. Each **policy** may have a different approval workflow, which consists in a sequence of steps, each composed of a combination of user roles. For an intent to be executed, all steps of the workflow shall sequentially receive enough approvals (quorum) to evaluate positively. The quorum can't exceed 2000 approvals per step. A single rejection fails the execution of the intent.

The locking of a **policy** ignores it entirely in the process of the policy selection.

## List policies

 - [GET /v1/domains/{domainId}/policies](https://docs.ripple.com/products/custody/v1.36/reference/api/openapi/policies/getpolicies.md)

## Get policy details

 - [GET /v1/domains/{domainId}/policies/{policyId}](https://docs.ripple.com/products/custody/v1.36/reference/api/openapi/policies/getpolicy.md)