# Policy

,Every action that touches a tenant's money runs through Policy. Policy is the rules a tenant has signed, expressed in plain English, compiled to deterministic checks, and evaluated on every proposed action.

### Three possible outcomes

| Outcome          | Meaning                                                    |
| ---------------- | ---------------------------------------------------------- |
| `auto`           | The action satisfies the policy and runs immediately       |
| `needs_approval` | The action is allowed but requires a human signature first |
| `rejected`       | The action is not allowed; structured reason returned      |

There is no fourth outcome. There is no override. There is no bypass.

### Plain-English in, deterministic out

A tenant writes:

> Allow invoice payments under $5,000 to approved vendors. Require CFO approval above $5,000. Block payments to new counterparties without review.

Brain compiles to:

```json
[
  { "if": "amount < 5000 && counterparty.known", "then": "auto" },
  { "if": "amount >= 5000 && counterparty.known", "then": "needs_approval", "approvers": ["role:cfo"] },
  { "if": "!counterparty.known", "then": "rejected", "reason": "new_counterparty_review_required" }
]
```

The tenant signs the **compiled** form. The compiler also returns a human-readable explanation so the tenant can verify the rules match their intent before signing.

### Versioning

Policies are versioned. A new version supersedes the old one. Past actions remain bound to whichever version evaluated them, which means the audit log is reproducible: anyone can replay any past decision against the policy that was active at the time.

### Where the rules live

Two layers, by design:

| Layer                            | Catches                                                                  |
| -------------------------------- | ------------------------------------------------------------------------ |
| **Off-chain Policy engine**      | Most violations, fast feedback, dynamic conditions                       |
| **On-chain `BrainSmartAccount`** | Anything the off-chain layer missed; protects against backend compromise |

The on-chain layer is the belt and braces. Even if Brain's backend were fully compromised, an attacker still couldn't push through a payment that doesn't carry a valid, non-expired, scope-bound policy verdict.

[**→ Smart contracts: BrainSmartAccount**](/smart-contracts/brainsmartaccount.md)

### The pre-execution gate

After Policy says `auto` (or after a human approves a `needs_approval`), one more check runs before money leaves: a deterministic 13-step gate that reads the **current** Ledger state. Account balance, counterparty status, idempotency, on-chain limits, audit-chain health.

Policy is the standing rule. The gate is the flight check. Both must pass.

[**→ Protocol: The pre-execution gate**](/protocol/the-pre-execution-gate.md)

### Why ESCALATE is the default

Any action that doesn't match a rule is **escalated for approval**, not auto-allowed and not silently rejected. This is intentional: new scenarios fail-safe, in front of a human, instead of silently going in either direction.

### What policy can express

| Concept             | Example                                                                        |
| ------------------- | ------------------------------------------------------------------------------ |
| **Amounts**         | `under $5,000`, `between $1k and $50k`                                         |
| **Counterparties**  | `approved vendors`, `new counterparties`, `to employees`, `to tax authorities` |
| **Account state**   | `if balance is at least $50k`                                                  |
| **Time windows**    | `weekdays 9am-5pm Pacific`                                                     |
| **Approvals**       | `require approval from CFO and CEO`                                            |
| **Outright denial** | `block`, `do not allow`                                                        |

For edge cases that don't fit plain English, you can author rules directly in the structured grammar.

### Privacy

Only the policy hash goes on-chain. The text and compiled rules stay encrypted in the tenant's partition. Counterparties verifying a policy decision check that the hash referenced in the verdict matches a hash registered on-chain. They don't need (and don't get) the rules themselves.

### Related

| Concept                            | Page             |
| ---------------------------------- | ---------------- |
| What Policy reads                  | Memory           |
| Who is subject to Policy           | Agents           |
| The audit record of every decision | Proof            |
| Deep dive                          | Protocol: Policy |


---

# Agent Instructions: 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:

```
GET https://docs.brain.fi/concepts/policy.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.