ROKRescue Operator Knowledge

How it works

How two-person sign-off works

Why an item needs a second approval, when ROK refuses to let one person publish alone, why approvals expire when content changes, and how policies make the rule automatic.

Some procedures are dangerous enough that one person's judgement shouldn't be the only thing between a draft and an operator's hands. Two-person sign-off makes ROK refuse the publish until someone else has read it.

The two-person sign-off gateAuthorwrites version 4Approvermust not be the authorPublishermust not be an approverPublishedexactly what was approvedsubmitsapproves v4count(distinct approvers) ≥ requiredAny material edittitle, summary or bodyv5approvals lapseHow many approvals are required is decided by the per-item flag and any matching policy, together.Once published, a gated item refuses material edits outright — unpublish or re-review instead.
Who has to agree before a gated item can be published.

What the rule actually is

An item that requires sign-off cannot be published until enough distinct people have approved its current version. The people who approve must be someone other than both the author and whoever is doing the publishing — so a single person holding every permission still cannot push it through alone. The same rule applies to releasing changes to an item that is already published, and to a scheduled publish, where the person who set the schedule counts as the publisher.

Approving requires the Second approval permission, and the system refuses an approval from the item's own author.

Approvals are pinned to a version

This is the detail that surprises people. An approval records the exact version it approved. Any saved change bumps the version — an edit to the title, summary or body, but also a status change, or a new cover, hero image or colour — and every approval given against the old version stops counting. Setting or moving a publish time is not a change to the item: approvals survive it.

That is deliberate. An approval is a statement about specific words, not a general endorsement of the item. If the words change, the statement no longer applies.

Editing gated content that is already published

Once a gated item is live, you can still edit it — even its title, summary and body — but the changes are held. Operators keep the approved version while you prepare the next revision. To send the changes out, someone gives the approvals on the new version, and then a person who holds Publish selects Release to operators on the item. The release is refused until the approvals are there, from people other than the author and the person releasing. Nothing unreviewed reaches operators in between.

Making it automatic

Flagging items one at a time doesn't scale. Approval policies apply the rule by rule instead: match on content type, on a tag, or on a guide — and a guide policy covers its sub-guides too. Each policy sets how many approvals it needs.

A per-item flag and any matching policies fold together into a single required count, so turning on a policy never quietly weakens an item somebody had already flagged by hand.

Manage them under Settings → Approvals (opens the admin console).

Scheduling doesn't dodge it

A scheduled publish runs the identical check when its time arrives, with the person who set the schedule as the publisher: approving an item and then scheduling it yourself does not count as two people. If approvals have lapsed because someone edited the item in the meantime, the scheduled publish is held back, and the item waits in the queue rather than shipping unapproved content.

See also

Last reviewed