Approvals and quorum
Every consequential change in Churchill, such as registering an application or authorizing a binary change, travels as a change request that your Change Advisory Board must approve. The CAB page (CAB in the sidebar’s Governance group) is where that happens. It lists every change request, shows how close each one is to quorum, and lets CAB members cast their receipts. This page covers the approval machinery itself. What happens around a binary change specifically is covered in Change control.
The CAB page
Section titled “The CAB page”The page header reads Security governance · CAB and shows your tenant’s quorum policy, for example quorum 2 of 3: two approvals required, three active members who can sign. Below it, five stat tiles count changes by stage: Pending approval, Quorum satisfied, Published, Rejected, and Expired. Filter tabs narrow the list to one of those stages, or to all.
Each row is one change request, and selecting a row opens its detail view. The columns are:
| Column | Meaning |
|---|---|
| CHANGE_ID | The change request’s unique identifier. You type this id to confirm final actions. |
| OP | The operation the change performs, in operator wording: Register application or Change control. |
| TARGET | What the change applies to, named where the console can resolve it: an application’s name rather than its id. Hover it to read the underlying id. |
| STATE | The change’s current stage, shown as a pill. See the stages below. |
| CREATED | When the change request was created. |
Below the list, the CAB members card shows the signing roster twice over: a roundtable ring with the chair pinned at the top, the other members and any outstanding invitations spaced evenly around it, and the seat and quorum counts in the middle; and beside it the roster itself, each member with their label, algorithm, fingerprint, state pill, and admission date. If you are the tenant owner, the card also carries the roster controls (Invite member…, Rename, Remove) and the pending-invitations list. See CAB overview for how the roster is managed.
Change-request stages
Section titled “Change-request stages”A change request moves through a fixed progression:
- pending approval: waiting for CAB receipts. The Cast a receipt card is available on the detail view.
- quorum satisfied: enough approvals have landed. The change now waits for an operator to publish it (or, for a binary change, to authorize the re-baseline).
- published: the decision is committed. For changes a host must pick up, the detail view’s lifecycle rail adds a fourth step, deployed, which fills in once the host has adopted the change. See Change control.
- rejected: a member vetoed the change. This is terminal.
- expired: the change sat unresolved for 7 days. Also terminal.
Casting a receipt
Section titled “Casting a receipt”A receipt is a passkey assertion from a CAB member over a challenge the control plane builds for this specific change. Your device signs it. No signature is ever pasted, and a receipt cannot be replayed onto another change.
Open a pending change. If your operator account is linked to an active CAB member, the Cast a receipt card shows your member label and two actions:
- Approve with passkey submits your approval in one step. Your device asks you to confirm with your passkey.
- Reject arms a confirmation: type the change id, then select Confirm veto. A rejection is final, so the console makes you spell it out. Cancel backs out.
Two states replace the actions when they do not apply. If your account is not linked to an active member, the card reads “You are not an active CAB member — signing is not available from this account.” If you already voted, it reads “You’ve already cast a receipt for this change.”
Quorum and the veto rule
Section titled “Quorum and the veto rule”Quorum is M approvals out of N active members. Each change’s Approvals card shows a segmented quorum bar reading, for example, 1 of 2 signed. A cast rejection is appended to the label, for example 1 of 2 signed · 1 rejected. When the last needed approval lands, the stage flips to quorum satisfied.
Rejection works differently: a single reject terminates the change request, no matter how many approvals it already has. There is no re-vote and no override. If the CAB wants the change after all, someone opens a new change request. For a binary change, a veto also feeds the deny flow described in Change control.
Publishing
Section titled “Publishing”Once a change reaches quorum satisfied, its detail view shows a Publish card. Type the change id to confirm, then select Publish change. Publishing commits the approved result and moves the change to published.
Binary changes show Authorize re-baseline here instead of Publish. The confirmation pattern is the same, the consequences differ. See Change control.
Every final action on this page (publishing, authorizing, denying, vetoing) asks you to type the change id first. This friction is deliberate. If the control plane refuses an action, the console shows its reason as plain inline text, for example quorum not satisfied or manifest diverged since approval.
Expiry
Section titled “Expiry”A change request that is still unresolved 7 days after creation shows as expired and can no longer be acted on. If the work is still wanted, open a fresh change request.
Provisioning codes and CAB invitations have their own, separate lifetimes. See Provisioning codes and Joining the CAB.
Who can do what
Section titled “Who can do what”- Any signed-in operator can drive the workflow: create change requests, open details, publish, authorize, and deny. Driving the workflow grants no approval power by itself.
- CAB members are the only ones who can approve or reject, because every receipt must carry a valid member assertion. The control plane verifies each receipt against the roster before counting it.
- The tenant owner is the only one who can invite, rename, or remove CAB members.
Receipts on record
Section titled “Receipts on record”Each change’s Approvals card lists every receipt cast so far: the member’s key, the verdict as an approve or reject pill, and the timestamp. Receipts, publishes, and denials all land on the tenant’s audit chain, so the full decision history of any change is reconstructable later. See Audit log.