Governance & Policy is where you decide how your organization governs AI operations — how much the AI may do on its own, when a human has to sign off, who gets told, and how long records are kept. The controls are grouped into eight plain-language policy sections.
Open it at Settings → Governance. It is an admin-level surface (the Admin role, plus platform admins), scoped to your own tenant. Every change applies live — there is no separate publish step — and the defaults reproduce today's behaviour exactly, so nothing changes until you change it.
1. AI Autonomy
Autonomy sets the baseline the other sections refine. Pick a mode that sets how much the AI does without you:
| Mode | What it does |
|---|---|
| Conservative | Maximum oversight. Every plan needs sign-off, the AI pauses on every approval gate, and revise/retry attempts are kept short. |
| Balanced (default) | Sign-off on risky or critical work; the AI keeps moving on routine work. This matches the platform's out-of-the-box behaviour. |
| Aggressive | Maximum throughput. No plan gate, the AI keeps building through gates, and approving a flagged change accepts it as-is. |
| Custom | Tune the underlying controls by hand. Choosing Custom reveals an Advanced panel with the individual switches (auto-revise limit, retry limit, pause-on-gate, reject-aborts, release step, resume-revise, and what "approve" does to a flagged patch). |
The plan-approval gate itself is driven by the Approval Policies section below, so the two never disagree.
2. Approval Policies
- When is human sign-off required? — the baseline gate before AI work ships: Never, Risky changes only, Production-impact, Security-sensitive, External integrations, Database changes, or Always.
- If no one responds in time — a default timeout (in minutes;
0= wait forever) and what to do when it elapses: pause, escalate, auto-reject, or notify a fallback approver. - Approval routing & stages — optional rules that refine the baseline. A rule matches on risk level (and, as the platform grows, workspace/integration), chooses the channels the approval is delivered on, and can chain stages (for example CTO → QA → Release Manager) each with its own timeout.
With no routing rules, the baseline applies to everything.
Plan approval before execution
When a gate requires it, the AI drafts a structured, versioned execution plan and waits for sign-off before it does any work — approach, affected systems, risk, validation, and rollback, all in plain language. The approver can Approve, Request changes (which re-plans, carrying the feedback into a new version), or Reject. A new version invalidates any earlier approval, so a plan can never change after sign-off. Whether this gate fires follows the autonomy mode and the baseline above (Conservative requires it on every plan; Aggressive disables it). For the operator's view of this, see Approvals.
Approving from email
Managers can approve or reject without logging in. To enable it:
- Configure outbound email under the platform Email (SMTP) settings (
SMTP_HOST,SMTP_FROM, and credentials). - Add an approval (or notification) *routing rule with the Email channel* enabled.
When a gate then opens, eligible approvers receive an email showing the issue, risk, verification summary, and a recommendation, with Approve / Request changes / Open details buttons. Each button is a single-use, expiring secure link; clicking it opens a short confirmation page and records the decision in FixControl — the same decision path as the in-app Approval Center.
3. Notification Policies
Decide who is told what, on which channel, when something needs attention. Each rule maps a trigger (approval required, patch failed, sandbox failed, mission completed, retry exhausted, risky patch detected, customer reply pending) to a role and a channel. This is additive — your managers still get the standard in-app notices; these rules add the specific routing you want (for example, "QA on sandbox failures").
4. Risk Policies
Classify which kinds of change are sensitive and what controls they trigger. For each category — authentication, billing, database schema, security-sensitive files, external API integrations, deployment/release, infrastructure — set a risk level (low → critical) and whether it requires approval, requires verification, or should escalate.
5. Verification Policies
What must be proven before a change can ship:
- Verification strictness — Lenient (verify the working tree, auto-revise on a failed sandbox run), Standard (the default), or Strict (verify a clean clone pinned to the run's commit, no auto-revise).
- Toggles to require a sandbox pass, require the test suite to complete, require QA sign-off, and block production-impact changes without QA.
6. Customer Communication
Controls whether and how the AI may talk to customers. This is an opt-in ceiling on top of your per-mailbox auto-reply settings — turn on Enforce these communication policies to activate it. When enforced it can only restrict automatic sending, never loosen a mailbox's own policy:
- AI response behaviour — never auto-send, draft only, auto-send high-confidence, or auto-send low-risk.
- Confidence thresholds — at/above the auto-send threshold the AI may send; between approval and auto-send a human approves; below approval it escalates.
- Allowed channels — where the AI may communicate (portal, email, Slack, API).
- Restricted topics — subjects the AI may never auto-handle (billing, legal, security, refunds, outages, or your own). The AI may still draft these for a human; it just won't send them automatically.
See also the user guide on auto-reply.
7. Escalation Policies
What happens when work stalls. For each trigger — retries exhausted, approval timed out, inactivity, SLA breach, stuck mission — set a delay and an action (notify a fallback, reassign, auto-reject, or page on-call) and a target role.
8. Audit & Retention
How long records are kept, in days (0 = keep indefinitely): agent traces, approvals, audit events, runtime logs, and customer communication. A scheduled sweep enforces these windows and also applies approval timeouts/escalation. Only categories with a non-zero window are ever pruned.
Safety model. Everything here is additive and opt-in: a tenant that never touches this page behaves exactly as before. Changes take effect immediately, and the "Balanced" autonomy preset is identical to the platform defaults.