---
summary: How ScaiCrew decides when a human must approve an action.
title: Approvals
path: approvals
status: published
---

# Approvals

Approval is **computed**, not configured ad hoc. The rule is:

> **approval = rigidity × effect class**

## Effect classes

Every tool a member can use has an effect class:

| Class | Examples |
|---|---|
| `internal` | Reasoning, scratch memory |
| `external_read` | Reading a file, querying an API |
| `external_write` | Sending mail, writing a record |
| `spend` | Anything that costs money |

## The rule

- Any `external_write` or `spend` action **requires human approval by default**, regardless of
  rigidity, unless it has been explicitly whitelisted.
- `external_write` / `spend` can **never be silently auto-approved** at compile time.
- Lower-risk classes follow the member's rigidity.

At compile time the compiler emits a `@checkpoint` wherever approval is required. At run time the
member **pauses** at that checkpoint and the run enters `waiting_approval`.

## Separation of duties

ScaiCrew **computes when** approval is needed and surfaces the decision in the Bridge's
[approvals queue](/docs/scaicrew/the-bridge). **ScaiQueue enforces** it — the actual hold-and-release of the
pending action lives in the execution plane. A decision (approve / reject) resumes or fails the run.