Team & enterprise guide

Guides

Team & enterprise guide

Multi-reviewer approval chains, RBAC, quorum policies, compliance mode, and org-wide oversight.

This guide is for organisations where multiple people review AI output — directors, compliance officers, legal, domain experts. The API is identical to the solo setup; what changes is the governance layer: who reviews, in what order, and what rules cannot be bypassed.

Setup steps

1
Invite your team
Go to Team in the dashboard and invite collaborators by email. Each invite is scoped to a role: Admin (full access), Reviewer (can approve/reject/edit), or Viewer (read-only). Invites are org-specific; members must accept before they can act.
2
Create an approval policy
Go to Policies and create a new policy. Choose a mode:
- anyFirst reviewer to act satisfies the policy. Fast, good for low-stakes output.
- allEveryone must approve. One reject terminates the item. Use for board communications.
- sequentialReviewers are notified in order; each step unlocks the next. Good for hierarchical sign-off.
- quorumn of m reviewers must approve. Flexible for panels and committees.
Example: a quorum policy with participants [Director A, Director B, Director C] and n=2 means any two of the three directors must approve before the webhook fires.
3
Attach the policy to an API key
Go to Connect → API keys and edit the key your pipeline uses. Select the approval policy from the dropdown. Every item submitted under this key will require the full policy to be satisfied before the on_approve webhook fires.

Configure the oversight gate for your compliance needs

Under Connect → key → Oversight, add always-review rules that capture your mandatory-review conditions. The gate runs before any policy check; items that match always-review rules go to a human regardless of confidence or auto-bypass rules:

json

// Items with segment="EU" always go to review — even at confidence=1.0
// Configure in Dashboard → Connect → <key> → Oversight → Always-review rules:
{
  "always_review_rules": [
    { "field": "segment", "op": "eq", "value": "EU" },
    { "field": "metadata.audience", "op": "eq", "value": "board" }
  ]
}

5
Enable compliance mode for zero-bypass keys
If a key handles content that must never auto-fire — regulated communications, financial advice, medical copy — enable compliance mode on the key. With compliance mode on, every item goes to review regardless of confidence, bypass rules, or sample rate. Only humans can approve.
Compliance mode + audit mode are mutually exclusive
Enabling compliance mode on a key disables audit mode for that key. An item cannot be simultaneously always-reviewed and always-auto-fired.

Submit items from your pipeline

The intake call is identical to the solo setup. Include a segment that matches your always-review rules, and set confidence so your threshold rules can evaluate it:

bash

curl -X POST https://yourapp.com/api/queue \
  -H "x-checkpoint-key: cpk_live_<TEAM_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "<p>Dear Board — Q2 results showed 23% YoY growth...</p>",
    "confidence": 0.79,
    "segment": "board-communications",
    "metadata": { "audience": "board", "region": "EU", "quarter": "Q2" },
    "on_approve_webhook": "https://comms.acme.com/webhooks/send-board-email"
  }'

7
Set a timebox so items do not stall
Under Connect → key → Oversight, set approval_timeout_minutes and choose an on_timeout_action. Recommended for team use: escalate_expire — the item expires and a notification is sent to all policy participants, creating an accountability trail in the audit log.

Notification routing

Beyond the approval policy, you control who is pushed a notification when an item lands for review. Each API key can carry a notify_config, set under Settings; a per-key config overrides the org-wide default. The config resolves org-scoped — stale or foreign ids are dropped, never pinged — and can target:

rolesall members whose base role matches (owner / admin / approver / commenter / viewer)
membersnamed teammates by membership
groupseveryone in a group you've defined
original reviewerthe reviewer who requested a regeneration — added live when the regenerated item returns

Empty config = notify nobody

An empty notify_config pushes to no one — there is deliberately no owners/admins fallback (it was unsolicited noise). Crucially, this does not silence approval policies: the reviewers a policy requires are always notified on top of the config. Only an item with no policy and no config goes un-pushed (it still shows in the queue). Configure recipients explicitly so the right people are alerted.

Every recipient also sees the notification in the in-app bell, with the full history at /dashboard/notifications. A live "who will be notified" preview is shown next to the config in Settings. Slack & Discord channels are coming to Settings.

Role reference

Role	Queue	Policies / Oversight	API keys	Team / Settings
Admin	Full	Full	Full	Full
Reviewer	Approve / reject / edit / comment	Read-only	None	None
Viewer	Read-only	Read-only	None	None

Recommended governance config

Setting	Recommended	Why
Policy mode	quorum (2 of 3) or sequential	Prevents single-reviewer bypass for high-stakes content.
compliance_mode	true for regulated content	Zero-bypass guarantee. Cannot be overridden by any rule.
always_review_rules	Add EU, board, legal segments	Deterministic, auditable — no confidence score can bypass these.
approval_timeout_minutes	120–480 (2–8 hrs)	Enough time for reviewers across time zones.
on_timeout_action	escalate_expire	Creates a paper trail; does not silently auto-approve.
sample_rate	0.05–0.10 on low-stakes keys	Spot-check 5–10% of auto-fire items for quality audits.

Using the audit log for compliance

Every decision — approve, reject, edit, timeout — is written to the immutable audit log with reviewer identity and timestamp. Export the log from Audit Log in the dashboard. For regulated environments, the audit log is the primary evidence trail.

Scaling from solo to team

If you started solo, you can add team governance without changing your integration code. The API key and /api/queue call stay the same. Attach a policy to the key, invite reviewers, and items that previously landed in your personal queue will now notify the full policy participant list. Your pipeline does not need to know the difference.

← Core concepts