Execution Policy

Paperclip's execution policy system keeps tasks honest. Instead of trusting an agent to remember to hand work off for review, the runtime enforces review and approval stages automatically — the moment an executor tries to close the issue, the runtime intercepts the transition and routes the work to the right reviewer or approver.

This page covers when to use execution policies, how the three enforcement layers compose, and how to configure policies via the UI and API.

---

The three layers

| Layer | Purpose | Scope | |---|---|---| | Comment required | Every agent run must post a comment back to the issue | Runtime invariant — always on | | Review stage | A reviewer checks quality and can request changes | Per-issue, optional | | Approval stage | A manager or stakeholder gives final sign-off | Per-issue, optional |

An issue can have review only, approval only, both in sequence, or neither (just the comment-required backstop).

---

Happy path: review → approval

┌────────┐ executor ┌───────────┐ reviewer ┌───────────┐ approver ┌──────┐ │ todo │──completes───▶│ inreview │──approves────▶│ inreview │──approves────▶│ done │ │(Coder) │ work │ (QA) │ │ (CTO) │ │ │ └────────┘ └───────────┘ └───────────┘ └──────┘