Governance & policy

Governance & Policy is where you decide how your organisation governs AI work: how much the AI may do on its own, when a person has to approve, who gets told, and how long records are kept.

This page stays on screen on purpose. It decides what every other action, including everything Command Center can do, is allowed to do. Command Center works under this page and cannot change it.

Opening the page

Open Settings → AI & approvals, or Governance in the main menu. Only administrators can open it; others see that the rules are managed by an administrator. If the page asks you to sign in again or set up two-factor authentication, follow the link first.

Every change applies live: there is no separate publish step. New work follows the new setting; for a few switches, work that is already waiting keeps the rule it started with (the confirmation says so).

The page opens with the everyday tabs: Overview, Approvals, AI Autonomy, Customer Communication and Safety Controls. Click Show advanced settings for Simulator, Notifications, Risk, Verification, Escalations and Audit & Retention, plus the level picker for workspace, project and environment overrides.

Posture and templates

At the top, Governance posture sets a baseline in one click. Applying a posture asks for confirmation; it updates the organisation-wide defaults for autonomy, approvals, verification, communication and retention, and leaves your routing, risk and escalation rules alone.

On Overview you also find Policy templates: Startup, Balanced, Enterprise, SOC 2, ISO 27001, Healthcare (HIPAA), Financial (SOX/PCI) and High-security. A template is a preset of settings across the same domains, applied immediately and reversible by applying another. A template is a starting point, not a certification: applying SOC 2 or ISO 27001 does not make your organisation compliant.

The rest of Overview shows the effective posture per domain and what would happen if the AI attempted each kind of action. Click a card to jump to that tab.

Approvals

Who decides

• Who may approve: the roles approval requests are routed to by default, in order. Without your own choice, requests are suggested to CTO and then Admin, and any active administrator or manager decides.
• Who holds which role: assign people to roles such as CTO, QA or Release Manager. Only administrators and managers can hold a role. Without staged approvals, roles only decide where a request is routed; one decision by an administrator or manager settles it.

When approval is needed

• Plan approval before execution: Always require plan approval, Only for risky or critical work or Never require plan approval. When a plan needs approval, the AI pauses after analysis until a person approves the execution plan; see Approvals.
• When is human sign-off required?: the baseline from Never to Always. It is applied to production deployments of changes FixControl made; it does not hold back code changes or pull requests. Those are gated by risk flags, the review agent's verdict and the sandbox check.
• If no one responds in time: a timeout in minutes (default 0, which means wait indefinitely) and the action when it passes: Pause the mission, Escalate, Auto-reject or Notify fallback approver.
• Approval routing & stages: rules that match approvals by risk to a chain of roles (for example CTO → QA → Release Manager) and choose the channels. The chain is only enforced with staged approvals on.

How approval rules are applied

This card has four organisation-wide switches. Each is off by default and asks for confirmation:

• Apply approval timeouts and escalations automatically: checks every five minutes and applies your timeout action and escalation rules. Off: they only act when someone runs the governance sweep, and a late request just keeps waiting.
• Enforce staged approvals: a request whose route has stages is decided stage by stage, in order, one person per stage. A route with three stages therefore needs three different administrators or managers. A no rejects at once.
• Risk rules may require a plan approval: your risk rules and safety controls can make a new plan wait for approval. This can only add an approval, never remove one.
• Projects may be less strict than the company policy: off means a project's own rule only applies when it is stricter than the company policy.

Where approval requests arrive

• In FixControl: always, on the issue and its mission.
• Slack or Teams: through a routing rule's channels or the project's approval channels.
• E-mail: needs FixControl's outbound e-mail (set up by FixControl) and an enabled routing rule with the Email channel. One such rule turns approval e-mail on for the whole organisation, and it goes to every active administrator and manager. The e-mail has approve and reject buttons only, each a single-use link that expires; for anything else, open the request in FixControl. Approval e-mails are in English.
• Webhook: approval requests are not sent over webhooks.

Deployment capabilities

Also on Approvals, Deployment capabilities decides what an approved deployment gate may do on your systems. All four are off by default, each asks for a reason, and every change is recorded in the audit log:

• Open gates for your own deployments: open an approval gate for deployments FixControl did not make. Records a decision; writes nothing.
• Carry the verdict back to the CI/CD host: let an approve or reject reach the waiting pipeline in GitHub Actions, GitLab CI or Jenkins (pilot).
• Promote a paused Argo Rollout: let an approval promote the next step of a paused rollout.
• Hand the verdict to an fc-agent in your cluster: your own FC Agent fetches an expiring authorisation and may still refuse it locally.

A gate can never start or roll back a deployment.

Project rules

On a project's Approvals & rules page, administrators can set rules for that project. A project rule applies only after it is reviewed and activated, and only when it is stricter than the company policy (unless Projects may be less strict than the company policy is on). The page shows per action whether the rule is actually enforced:

AI Autonomy

Pick a mode: Conservative, Balanced (default), Aggressive or Custom. Custom opens Advanced controls: auto-revise limit, retry limit, pausing work on a gate, whether a rejection aborts the mission, a release step, resuming a revision, and what approving a flagged patch does. These are organisation-wide defaults; the plan gate itself is set under Approvals.

Customer Communication

An organisation-wide ceiling on what the AI may do with customer replies: response behaviour, confidence thresholds, allowed channels and restricted topics. It is advisory until you switch on Enforce these communication policies (off by default; Overview shows Advisory — not enforced). Enforced, it can only restrict automatic sending, never loosen it.

Day-to-day sending and approval is set elsewhere: per project under Approvals & rules → Replies to customers, with organisation defaults under Settings → Customer communication → Sending & approval. See Replies to customers.

Notifications

Rules that send a notice to a role on a channel when something happens: approval required, patch failed, sandbox failed, mission completed or failed, retry exhausted, risky patch detected, customer reply pending. They add to the standard notices. For mission status notices, only FixControl and Slack deliver today; an e-mail, Teams or webhook route is kept but recorded as skipped, and the screen says so.

Risk

Per category (authentication, billing, database schema, security-sensitive files, external APIs, deployment, infrastructure, Terraform, Kubernetes, secret rotation, DNS, feature flags) you set a risk level and whether it needs approval, verification or escalation. Risk rules show up in Overview and the Simulator; they make a new plan wait for approval only when Risk rules may require a plan approval is on.

Verification

• Verification strictness: Lenient, Standard or Strict.
• Require a sandbox pass before approval. Independently of this switch, FixControl only delivers a patch after a green sandbox run.
• Require the test suite to complete, Require QA sign-off and Block production-impact without QA are recorded with the policy; the screen says where no gate enforces them yet.

For applications with supporting services, FixControl can also require full environment evidence (which services and image versions the passing run used). This is off by default, part of the multi-container pilot, and switched on by FixControl rather than on this tab. See Projects.

Escalations

Per trigger (approval timed out, stuck mission, inactivity, SLA breach, retries exhausted) you set a delay, an action (Notify in FixControl, Reassign the issue and notify, Reject automatically, Notify in FixControl and by e-mail) and a target role. They only act when Apply approval timeouts and escalations automatically is on, or when the governance sweep runs.

Audit & Retention

How long records are kept, in days. Every field defaults to 0, which means keep indefinitely. Each category has a minimum; a value between 1 and that minimum is refused.

• The approval window counts from the decision, not from when the request opened. A request that is still waiting is never touched.
• Patch content follows the approval window. The code, prompt and context of a patch are redacted with the approval that covered it; the file list, line counts per file and the patch fingerprint stay, so you can still prove which exact patch was verified and approved.
• Audit events show as Platform-managed. On the hosted service FixControl keeps audit events for 365 days, never less than 90; you cannot change this window here.

Below the settings, Audit trail lists audit events with filters and search. Its status badge shows when FixControl last checked the hash-chained, append-only audit log. Export downloads the events on the current page as a JSON file.

Safety Controls

Emergency switches for the whole organisation: Stop all agents, Read-only mode, Disable deployments, Disable customer communication, Disable external integrations and Maintenance mode. Each asks for a reason and can lift itself automatically.

Read the screen carefully: today these switches act in the Overview previews, the Simulator and policy evaluation. Deployments, customer messages, integrations and running agents do not check them yet. Only with Risk rules may require a plan approval on do Stop all agents and Read-only mode hold or block a new plan.

When something goes wrong

• Approvals never time out. The timeout is 0, or Apply approval timeouts and escalations automatically is off.
• Staged approvals stall. A stage needs a different person than the previous stages. Check Who holds which role and that you have enough administrators and managers.
• No approval e-mails arrive. Check that an enabled routing rule has the Email channel. If it still fails, contact FixControl support about outbound e-mail.
• A project rule doesn't apply. It may still be waiting for review, or it is not stricter than the company policy.

Related: Approvals, Verification, Delivery, Replies to customers.