> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/guides/governance/policies.md). # Policies How to create, read, edit, and reuse Policies on Ledger Enterprise, and how to judge the blast radius of a change. **Role: Administrators write. Operators read.** A Policy is a reusable, named Rule set. One Policy can govern many Accounts, so editing it changes the governance of every adopting Account at once. That is its value and its risk. ## The Policies list Policies are listed most recently updated first. Each row shows the name, the asset or an any-asset badge, how many Rules it holds, and when it last changed. Sort by name or last updated, and filter by name or asset. Your filters are kept in the page address, so a filtered view can be shared or kept for audit. Only shared Policies appear here. An Account using its own Rules is backed by an automatically named private Policy, deliberately hidden. ## Single-asset or any-asset The first decision when creating a Policy is whether it applies to **one** asset or **any** asset. It defaults to any asset.
ChoiceAmount thresholdsWhich Accounts can adopt it
Single assetAvailableAccounts holding that asset only
Any assetNot availableAny Account
Thresholds only mean something against a known unit, so an any-asset Policy cannot carry them and the combination is rejected. > **Important:** This choice, and the asset itself, is **locked once the Policy exists**. You cannot convert a single-asset Policy to any-asset later. If you need the other shape, use the Policy as a template and create a new one. Choose any asset when the approval chain is the point and amount banding is not, for instance one counterparty's governance across their whole treasury. Choose a single asset when you need tiered thresholds. ## Creating a Policy The create flow opens on its own page. It asks for: * A **name**, up to 45 characters, unique in the Workspace * An optional **description** * The **asset binding**, single-asset or any-asset * One or more **Rules** Each Rule collects:
FieldNotes
Operation typeSend, Receive, Stake, and the other governed operations
ReviewersOrdered approval steps, each with members and a quorum
WhitelistsOptional, multi-select. The Rule permits the combined set of their addresses
ThresholdOptional minimum and maximum, in the bound asset. Single-asset Policies only
Rule counts are capped per operation type. You can add up to **four Send Rules**, checked in order, with the first matching threshold applying. Every other operation type allows **one** Rule. A Send Rule is always required. See [**Limits**](/help-center-v2/reference/limits.md). Submitting creates a Policy Request and takes you to it. Once approved, the Policy appears in the list and becomes selectable when creating or editing an Account. An any-asset Policy can be adopted by any Account; a single-asset Policy only by Accounts of that asset. > **Note:** Write the description. It is what a colleague reads during an audit, months later, when the reasoning behind a quorum is no longer obvious. ## Reading a Policy Opening a Policy shows its description and dates, the Request that last changed it, and: * **Rules**, each with its operation type, approval steps and members, threshold where applicable, and the Whitelists it references, which you can click through to. * **Used by Accounts**, every Account that has adopted it. **Check this before every edit.** Operators see only Accounts they have visibility on. * **Whitelists referenced**, every Whitelist any Rule points at. Administrators only. * **History**, every creation and edit Request on this Policy with who requested it, who approved it, when, and the payload. This is your audit trail. If a Request is pending on the Policy, a badge says so and the edit and template actions are disabled until it resolves. ## Editing a Policy Name, description, and Rules are editable. The asset binding is not. Submitting creates an edit Request. While it is pending, the Policy is locked against further edits. The lock applies to the interface and the API alike. The list and the detail view both link to the pending Request. Once approved, **the new Rules take effect on every adopting Account simultaneously**. Account Requests already in flight are not invalidated: they complete and then fall under the updated Rules. > **Important:** Read **Used by Accounts** first. A quorum change that is sensible for one Account may be unworkable for another that adopted the same Policy for different reasons. ## Use as template To create a sibling Policy, use the template action from the list or the Policy detail. The create form opens pre-filled with the source's asset binding, description, and Rules, with the **name left empty**. On a template the asset binding **is** editable, since the Policy does not exist yet. Converting single-asset to any-asset drops the thresholds; converting any-asset to single-asset gives you empty threshold fields to complete. The new Policy's history records which Policy it was templated from. ## What Policies do not do yet * **No drafts.** Either submit or abandon; a closed form is not kept. * **No archive or delete.** Obsolete Policies stay in the list. * **No creation from the Account form.** Provision the Policy first. * **No bulk assignment.** Accounts adopt a Policy one at a time. * **Read-only through the API.** Policies can be read programmatically but not created or edited that way. The interface is the only write surface. ## Related * [**Whitelists**](/help-center-v2/guides/governance/whitelists.md) * [**Creating and editing Accounts**](/help-center-v2/guides/accounts/creating-and-editing-accounts.md) * [**How governance works**](/help-center-v2/concepts/how-governance-works.md) * [**Limits**](/help-center-v2/reference/limits.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.enterprise.ledger.com/help-center-v2/guides/governance/policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.