CONTROLS / ELPIS
Approval
Exactly when a person must decide, and how the decision is recorded.
What triggers approval
| Required by | When |
|---|---|
account.approval_limit | Amount is at or above the pool’s approval threshold. |
account.autonomous_limit | Amount exceeds the pool’s autonomous limit. |
account.recoverability_requirement | The class is weaker than the pool allows unattended. |
policy.irreversible | The action is R4 — nothing can take it back. |
policy.recipient_changed | The recipient’s wallet details changed (also blocking). |
policy.new_counterparty | First payment to an unknown counterparty. |
policy.document_anchor | A payment above the threshold cites no document. |
policy.amount_anomaly | Amount is far outside the counterparty’s own history. |
policy.daily_autonomous_limit | Today’s autonomous budget is exhausted. |
supervisor.freeze | The supervisor froze the action. |
What an approval contains
requiredBy— the exact controls that asked. Never a generic “needs review”.reasons— plain-language sentences, shown verbatim in the console.threshold— a suggested limit, when one would have avoided the escalation.expiresAt— approvals are time-bounded, not open indefinitely.
An approval only exists because a control asked. Resolving it does not skip the control — it records that a person accepted it, which is why the ledger keeps both the ask and the answer.
Who can approve
Approval needs the approve scope. Agent keys are issued with read and propose only, so an agent can raise an approval but never answer one. This is deliberate: it is the boundary between suggestion and authority.
Resolving
- Approve — the action proceeds (still through execution and verification).
- Reject — terminal. No money moved, so there is nothing to unwind.
- Expire — treated as a rejection, not as consent by default.