> 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/concepts/how-governance-works.md).

# How governance works

The Request lifecycle behind every action on Ledger Enterprise: approval steps, quorum, which Rule applies, and what expires.

Read this page once and every guide gets shorter.

## What a Request carries

<table><thead><tr><th width="150.8125">Part</th><th>Meaning</th></tr></thead><tbody><tr><td>The operation</td><td>What it does, with its full details</td></tr><tr><td>Approval steps</td><td>Ordered stages, each needing a set number of approvals</td></tr><tr><td>Quorum</td><td>How many approvals a given step requires</td></tr><tr><td>A note</td><td>Optional free text from whoever created it, visible to Approvers</td></tr><tr><td>An expiry</td><td>If full approval is not reached in time, the Request lapses and does nothing</td></tr></tbody></table>

Steps are collected **in order**. Reviewers at step two cannot act until step one has met its quorum. Every Request shows how many approvals it has out of how many it needs.

> **Note:** A person who belongs to several groups named in the same step counts **once** toward that step's quorum. When you design a step, check its quorum is actually reachable by the distinct people in it.

## Creating a Request

In the interface, you fill in a form, then review it on your Ledger device. The device shows the operation's real details, read from the secure hardware rather than from your browser. What you approve is therefore what executes.

An API user creates the same Request over the API, and signs it with its own key.

After you approve:

* **If yours is the only approval needed**, you get a confirmation and the operation proceeds.
* **If others must approve**, you see how many approvals remain and can copy a link to the Request to share with them.

## Approving and rejecting

Open **Requests** to see what is waiting on you.

* **Approving is signed with your own key.** In the interface you confirm on your device, the same details the Creator did. An API user signs the approval challenge instead.
* **Rejecting ends the Request permanently.** It cannot be revived, so the operation must be created again. In the interface, rejecting needs no device confirmation. An API user signs a rejection as it signs an approval.

You can only approve at the step you belong to, and only while that step is the current one. See [Request statuses](/help-center-v2/reference/statuses-and-errors.md#request-statuses) for more details.

## Which Rule applies

Governance is defined **per operation type**. The Rule governing a transfer is not the Rule governing a smart contract interaction, and each Account carries its own set.

Every Account must define who may **send**. Rules for staking, message signing, contract interaction, contract deployment, and other specific cases are optional. They appear only where the asset supports them.

Canton Accounts also need a **receive** Rule, because receiving on Canton is an action somebody has to approve. See [Canton](/help-center-v2/reference/networks/canton.md).

An Account can hold up to **four Send Rules**. They are evaluated in order, and the first whose amount threshold matches applies. This is what makes tiered approval work: modest amounts under a light Rule, large amounts under a heavier one. Every other operation type allows a single Rule.

When you create a transaction, the form names the **matching Rule**. That is the Rule your Request falls under. Four things determine it: the Account, the operation, the amount, and whether you are a permitted Creator.

The matching Rule states how many approvals this transaction needs.

If no Rule covers what you are attempting, the Request cannot be created. That is **a governance outcome rather than a fault**. Ask an Administrator whether the Rule set is what your organization intends.

## Where Rules live

An Account is governed either by **its own Rules**, used nowhere else, or by a **shared Policy** that other Accounts also use. A Policy is a reusable, named Rule set, so editing one changes the governance of every Account that adopted it at once. See [**Policies**](/help-center-v2/guides/governance/policies.md) and [**Whitelists**](/help-center-v2/guides/governance/whitelists.md).

## Related

* [**The security model**](/help-center-v2/concepts/the-security-model.md)
* [**Requests and approvals**](/help-center-v2/guides/requests.md)
* [**Governance**](/help-center-v2/guides/governance.md)
* [**Glossary**](/help-center-v2/reference/glossary.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/concepts/how-governance-works.md?ask=<question>&goal=<endgoal>
```

`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.