Policies

A policy is the set of rules a request is decided under: how many keys, in what mode, inside which windows, who is eligible, and whether the requester may count. Every request runs under one policy, frozen when the request is created.

The settings

Setting	What it does
Quorum	How many distinct operators must commit.
Mode	counted accepts commits in any order until the quorum is met. coincident needs every commit inside one shared arm window, and reissues codes if a round collapses.
Request TTL	How long the request stays live before it expires unmet.
Arm window	How long a box stays armed waiting for the press. In coincident mode this is the shared window.
Code TTL	How long an arming code stays valid.
Eligible	Who may stage. Empty means any member of the organization.
Self approval	Whether the requester may count toward their own quorum. With it denied, the requester gets no code for their own request.

The starter set

Every organization starts with the same set of policies, listed on the dashboard. A policy is available once the organization has enough members to satisfy it; the rest stay listed with the headcount they need.

Policy	Keys	Mode	Self approval	Needs
Solo	1	counted	allowed	1 member
One of the team	1	counted	denied	2 members
Two keys	2	coincident	denied	3 members
Two keys, any time	2	counted	denied	3 members

An organization with one member has Solo available and nothing else, and every request runs under it. A request for an action your organization doesn’t hold is refused with a 422.

Headcount

With self approval denied, the requester is struck from their own request, so a policy with a quorum of N needs N plus one eligible people. The dashboard won’t enable a policy the organization can’t satisfy, and the server refuses a request that would leave a shortfall.

Custom policies

An admin creates a policy per action on the dashboard, starting from one of the set or from scratch. Each of quorum, mode and the three windows is either pinned or selectable within bounds: a quorum between a minimum and a maximum, a mode from an allowed set, a window up to a limit. Eligibility and self approval are always pinned.

Your own actions

Integrations bring their own actions, like GitHub’s deploy.production. An admin can also add actions of your own on the policy screen: treasury.transfer, database.restore, whatever your service does. An action is an id, a label and the policy above, and it can declare the params it takes, in order. Pick an id no integration provides. Outis routes an action to its integration by id, so it answers a clash with a 409.

Nothing in Outis executes your own action. Once enough keys turn, the request goes from authorized straight to succeeded, and your service runs it after it reads the decision and checks the operation hash.

The panel draws the label as the title and the first param as the subject, then the first six characters of the operation hash, labeled SHA, and the rest. Declared params go first, in the order you declared them, and any others follow in key order. Put the param that tells two requests apart first.

What a request may choose

A request may set quorum, and only when the action marks its quorum selectable, within its bounds. Leave it out and you get the policy’s default, or what its param rules answer. With param rules that answer is a floor, so a value below it is a 422, and so is one outside the bounds. Everything else comes from the policy. See Create a request.