How approval works

A request moves from proposed to decided through a short ceremony on physical boxes. Your service starts it and reads how it ended.

The ceremony

1. Propose. Your service, or an integration acting on an event, creates a request naming an action. The server looks up the action’s policy and works out who is eligible.
2. Notify. Each eligible operator is sent an arming code over a channel they’ve linked, usually a Slack DM.
3. Stage. An operator turns the keyswitch on their box, types the code and sees the request on the glass.
4. Arm and commit. Once the policy’s conditions are met the box arms, and the operator presses the guarded button. That press is the commit.
5. Decide. When enough operators have committed inside the window, the request is authorized. If the window closes, the request expires, or an operator aborts, it ends with a different outcome.

Quorum, modes and who counts

Every request runs under a policy: how many keys, whether they turn in any order or inside one shared window, how long each phase lasts, who is eligible, and whether the requester may count. A one person organization starts with a policy that needs nothing configured. Policies with more keys become available as the organization grows.

What the operator sees

The box draws a title, a subject and up to two labeled fields from the request, inside the payload box. The system band, the quorum row and the key legend belong to the device. GitHub requests also draw the six character digest of the params, labeled SHA, so an operator can check the request on the glass against the one in your logs. Design the panel has the limits.

The decision

A live request has no outcome. Once it ends, outcome is one of four values.

OUTCOME	MEANS
authorized	Enough distinct operators turned their keys inside the window. Act on it.
denied	An operator refused it.
expired	The request TTL ran out with the quorum unmet.
aborted	Withdrawn, by an operator's ABORT key or by the system.

authorized says the people agreed. Whether the thing then happened is recorded separately, as succeeded or failed in the request’s state.

The audit log

Every transition, accepted or refused, is appended to an audit log with a snapshot of the policy in force. Records are never edited or removed. The dashboard reads the log for the organization. An arming code is never logged.