Approvals

What an approval is

An approval is a pause button. At the moments that matter, FixControl holds the work and waits for a human — you — to say yes or no. That pause point is called a gate. The AI prepares the work; you approve the meaningful steps.

By default, nothing is sent, executed, or merged without an explicit human choice, and the approval is where that choice is made and recorded. The exceptions are opt-in and bounded: policy-scoped auto-reply sending and per-project auto-delivery of approved patches act only within guardrails a human configured, and every automatic action is recorded in the audit trail.

Which gates open and when is decided org-wide in Governance & policy. This page is about how you handle an approval once it's in front of you.

The two main gates

When fixing a bug or shipping a feature, you may meet two kinds of approval:

Plan approval is where you have the most leverage: you steer the AI before any work is done, instead of rejecting a wrong patch after the fact.

Plan approval — approve the plan before execution

Before the AI starts on a bug or feature, it can first draft an execution plan. That plan shows up as a card on the issue page, titled "Awaiting plan approval" while your decision is still open.

The plan is structured and in plain language — not a wall of code, but the reasoning:

• Problem interpretation — what the AI thinks the problem is.
• Proposed approach — how it intends to solve it.
• Affected systems / files — what gets touched.
• Risk level & risk reasons — how dangerous this is, and why.
• Validation strategy — how it will prove the change works.
• Rollback plan — what happens if it goes wrong.
• Customer impact, estimated time & cost, open questions.

Empty fields show "Not available" — FixControl never fabricates a value. An empty rollback plan is a real signal, not an omission.

Your three choices

The plan card ends with three buttons:

• Approve plan — the AI may start, following this plan.
• Request changes — you don't agree yet. You type, in a required field, what should change, and the AI produces a new version of the plan with your feedback folded in. You then review v2 (and so on). The feedback is recorded in the audit trail.
• Reject plan — you don't want this. The mission stops.

Every plan has a version number (Plan v1, v2, …). Important: a new version invalidates an earlier approval — you always approve the version in front of you, never an old one. A plan can never quietly change after your sign-off.

Until the plan is approved you'll see "Implementation is blocked by governance policy until this plan is approved." The AI genuinely won't start before then.

Patch approval — approve the change before it lands

Once the AI has produced a patch (after an approved plan, or directly, depending on your policy), it appears in the Patch panel on the issue or workspace page. There you see the proposed files, the diff, and a short review:

• Confidence — how sure the AI is of its own work.
• Risk — an independent judgement on the consequences. High confidence and high risk is a normal combination — read both.
• Blast radius — how much is affected.
• What changed — a plain-language summary.

If a reviewer (for example the CTO agent) asked for changes, you'll see a gate with two options:

• Approve & revise — you agree with the requested change; the AI produces a revised patch.
• Reject — discard patch — you turn it down; the patch is dropped and the mission stops.

A patch never lands in your codebase without an approval. By default, approving marks it accepted and Apply is a separate click that writes it out. A project can opt in to auto-delivery, where approval automatically applies the patch and opens a pull request on the bound repository — merging that pull request is still a human action in your git provider. See Workspace and Issues for the patch flow per surface.

Where to find pending approvals

An approval never sits only on the issue page — FixControl makes sure you don't miss it:

• On the issue or AI-execution page — as a card, right next to the work it belongs to.
• The Approval Center — a mission's blocking human gates gathered together, each with a summary.
• Notifications — the bell and the Action items page show "waiting on you"; pending approvals appear in the action-needed rail.
• Email — if your org enables email routing, authorized approvers get a message with Approve / Request changes / Open details buttons — without logging in (see below).

Who can approve

Every gate has a required approver (a role, e.g. CTO or QA). If you can see the plan or patch but no buttons, it tells you who can sign: "Only [role] can approve this execution plan." You're reading along, but the decision belongs to someone else.

Approvals can also be staged — for example CTO, then QA, then Release Manager — each with its own deadline. Your admin configures this under Governance.

Approving from email (without logging in)

If your org has outbound email and email routing enabled, you can handle a gate straight from your inbox. The email carries the issue, the risk, a verification summary, and a recommendation. Each button is a one-time, expiring secure link: clicking it opens a short confirmation page and records your decision in FixControl — through exactly the same path as the in-app center. Handy for managers who aren't in FixControl all day.

Your admin enables it; see Governance & policy → Approving from email.

What if no one responds in time?

A gate can have a timeout. If it lapses, what happens is whatever your org configured: pause, escalate to a backup approver, or auto-reject. This is governed by the escalation policy. By default a gate simply waits for you.

FAQ

I can see the plan, but no buttons. You aren't the required approver for this gate. The card states who can sign.

I chose "Request changes" — now what? The AI produces a new plan version with your note folded in. You then review that new version. Your note is required and recorded in the audit trail.

Does my approval still count if the plan changes afterwards? No. A new version invalidates your earlier approval — you always approve the version in front of you.

What's the difference between rejecting a plan and rejecting a patch? Rejecting a plan stops the mission before any work is done. Rejecting a patch discards a change that's already been made. Both stop the mission; only the moment differs.

Does an approved patch land in my codebase automatically? By default, no — approving accepts the patch and Apply is what writes it out. If your project has opted in to auto-delivery, approval applies the patch and opens a pull request automatically; merging it stays with you.

See also: Issues · Workspace · Governance & policy.