Approvals
Write approval policies
Decide which requests run on their own, which need a person, and who that person is, with rules in YAML.
Transcript (30 seconds)
Policies decide what runs alone and what needs a person.
Write rules in YAML. The first match wins.
Simulate a draft against the last thirty days.
Publish from the editor or from CI.
Every version is signed and kept.
Before you start
- An owner, admin or policy editor role
- For CI: an API key with policies:write
Steps
Write the rules
Rules are checked in order and the first match wins. Conditions use CEL over
args. A default rule is required.policy: support rules: - id: small-refunds match: { action: payment.refund, when: "args.amount <= 50.0" } effect: auto_approve - id: larger-refunds match: { action: payment.refund } effect: require_approval approvers: [group:support-leads] timeout: 4h on_expire: reject default: effect: require_approval approvers: [role:owner, role:admin]Test against history
In Policy, edit the draft and press Simulate. It replays the last 30 days and shows which past requests would decide differently.
Publish
Publish from the editor, or from CI with the CLI. Each version is kept and signed; pending requests keep the version they started with.
pc policies validate .promptcompute/ pc policies push .promptcompute/policy.yaml --note "Raise auto limit to $50"Need two people
Add
required_approvals: 2to a rule. Two different people must approve, and any reject ends the request.Escalate
Add
escalatesteps to notify the next group when time runs out. At the final timeout,on_expirerejects or denies; it never approves.
Use cases
Auto-approve the routine
- The situation
- Most refunds under $50 are always approved and approvers are tired of them.
- What to do
- Add an auto_approve rule with a condition on amount, simulate, then publish.
- What happens
- Small refunds run at once, and only larger ones reach people.
Two people for production
- The situation
- Database changes in production need a second pair of eyes.
- What to do
- Match the action and require two approvals from the platform group.
- What happens
- Nothing runs until two different people approve.
What you will see
New requests follow the published version; the request page names the rule that matched.
It worked when
- The request page shows rule small-refunds or larger-refunds
- Auto-approved requests show Approved by policy
- Policy lists each version with who published it and the note
Example output: pc policies push
Validated .promptcompute/policy.yaml: 2 rules and a default
Published version 4 for production ("Raise auto limit to $50")If something goes wrong
- Validation fails on a condition
- Conditions are CEL. Compare numbers as numbers (
args.amount <= 50.0) and quote strings. - A request matched the default rule
- Check the action name and the condition. Simulate shows which rule each past request matched.
- Approvers named by group get nothing
- The group key must exist under Approver groups. Until it does, requests go to owners and admins.