Documentation
Plan

45 of 187 pages

AI Product Studio

Gate Exceptions & Expiry

An exception is a person taking responsibility for a checklist item not being met on one work package. It records who granted it, under which authority, why, and until when — and once it has run out, the item is unmet again.

Three things, one record

Waiving an item (Does not apply), standing in for an item’s agent (Override Agent) and overriding the reviewer agents on a gate are the same kind of decision, so they are the same kind of record. Each opens Grant an exception, asks for a justification, and may carry an expiry in days.

Who may grant one

On your studio’s own items — a studio owner or reviewer. An expiry is optional and the dialog starts on No expiry: a lone developer’s own waivers should not lapse on them weeks later.
On an item from your organisation’s guardrail policy — the policy decides. It may forbid exceptions altogether. Where it allows them, an expiry is required. Where the policy names approver roles, only someone who holds one of them may grant, renew or waive — through the roles your studio maps the organisation’s roles to on Human Roles. That includes the studio’s owner: being the owner or a reviewer is not enough without the role.
Overriding the reviewer agents — a studio owner or reviewer, with a justification and a tick that the exception is taken knowingly. On a gate that holds an organisation item whose policy names approver roles, you must be an owner or reviewer and hold one of those roles.

The dialog tells you which rules apply before you write the justification.

How long an organisation item may stay under exception

A policy’s limit is the item’s time under exception in all, from the first exception to it on the work package — not a limit on each grant. A renewal does not start the time afresh, and nor does an exception granted again after the package changed or the item was decided again. The dialog says how many days are left and the date the time runs to, and will not take an expiry beyond it. Once the time is used up the item has to be met; only a new version of the organisation’s policy starts a new count. Your studio’s own items have no such limit.

Answering an agent is not an exception. When an agent asks a person a question and you answer Met, you are saying the item is met. That has no expiry and no time limit. On your studio’s own items it follows the usual rule — an owner, a reviewer, or the item’s named reviewer role. On an item from your organisation’s guardrail policy it needs the role the organisation names for that item, or, when the item names none, one of the policy’s exception approver roles — as your studio maps them. Where the organisation names neither, the rule for your own items applies. Being the studio’s owner or a reviewer is not enough there. Anyone who can assess may still answer Not met.

In force, expired, voided

In force — the item counts as waived.
Expired — its time ran out. The item is unmet until the exception is renewed or the item is met.
Voided — something cut it short: a material change to the work package, a new decision on the item, the review being started again, or a renewal replacing it. For an agent’s side of an item that reads the pull request, a new commit voids it too.
Retired — an override of the reviewer agents, once the agents approve the same version themselves. The gate then rests on their approval, so the override’s expiry no longer matters — to the gate, the Passport or a pipeline’s passport check — and it does not come back if the agents later stop approving.

Exceptions are never edited or deleted. One that expired and was later renewed stays listed as history — Expired, since replaced — and is not a problem to fix.

What happens when one expires

Nothing that has already happened is undone. A dispatched package stays dispatched, an approved release stays approved, and a completed package’s merge stays released. What stops is the next step: approving, dispatching and completing the work package, and approving or releasing a release that contains it, are refused until the exception is renewed or the item is met.

Nothing runs at the moment of expiry. The state is worked out from the date whenever the gate is read, so an open page shows it at its next refresh, and the merge status on GitHub is brought up to date at the next gate change or pull request refresh rather than on the minute.

Renewing

Renew is offered on the item, in the banner and in the gate’s Exceptions list. It grants a new exception that names the one it replaces, under the same rules as a first grant — the same people may renew, and on an organisation item the renewal counts against the same time. Renewal is the one change a gate that has already passed accepts — the gate stays passed and the package carries on. An exception with no expiry needs no renewing.

Reopening the gate instead

The other way through is to decide the item properly. A studio owner or reviewer can reopen a gate that has passed; doing so retires the person’s Go, which is kept in the decision history, and the gate needs a fresh one once the items are settled. The same happens when someone decides again an item that was already settled on this version: a Go given over decisions that no longer stand does not carry.

One person on both sides

By default the person who grants an exception may also have approved the item’s other side. Where that happened the dialog says so before you grant, and the gate, the Passport and the organisation’s register all show it. To require two different people, turn on separation of duties under Trust Settings — or an organisation’s policy may require it.

Where exceptions show

The gate — an Exceptions list beneath the checklist.
The Passport — on the work package and on any release that contains it.
Verify — at the head of the findings ledger.
The organisation’s Exceptions Register — if your studio belongs to an organisation, its administrators see every exception on your gates, including those on your studio’s own items, with who granted it and the justification.

All Guardrails, Evidence & Passport documentation

Build v0.3.2 · deployed 2026-10-19T23:52:31Z