Approvals

Write approval policies

Decide which requests run on their own, which need a person, and who that person is, with rules in YAML.

About 10 minutes

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

Steps

  1. 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]
  2. 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.

  3. 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"
  4. Need two people

    Add required_approvals: 2 to a rule. Two different people must approve, and any reject ends the request.

  5. Escalate

    Add escalate steps to notify the next group when time runs out. At the final timeout, on_expire rejects 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

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.