How re-validation works

Procedures go stale. Equipment is replaced, a technique is revised, a contact number changes — and the guide on an operator's phone still says what it said the day it was published. ROK puts a clock on every published item so that someone is prompted to confirm it is still right. By the end of this page you'll know how an item's due date is worked out, what does and doesn't restart the clock, who is reminded, and why "due" on Review due and "due" in the review queue are different things.

Each type has its own interval

How long published guidance may go unconfirmed is part of your agency's review policy, set under Settings → Review policy (opens the admin console) by people who hold Manage settings. There is one default interval — 365 days for a new agency — and an optional override per content type, anywhere from 1 day to 10 years. A swiftwater checklist might fall due every 180 days while a background article runs to two years.

The setting is stored once and read in two places: by the console — Review due, the calendar's review markers and the dashboard's Going stale widget — and by the database itself, for the daily reminder. That is why no two screens disagree about what "overdue" means. If the setting is missing or unreadable, everything falls back to 365 days.

The clock runs from the last review

An item's due date is its last-reviewed date plus the interval for its type; an item that has never been reviewed counts from the date it was published. Due dates are worked out when they are needed rather than stored, so changing an interval moves every due date at once — shortening it can put a batch of items on Review due the moment you save. Only published items have a clock.

What restarts the clock

Three things set the last-reviewed date to now, and all three need Publish:

• Mark reviewed, on Review due (opens the admin console) or for a selection in the bulk actions on All content. The content is untouched: its version doesn't change, approvals and operators' acknowledgements stand, and operators notice nothing.
• Publishing it from the editor. You are recorded as its reviewer.
• Saving it from the editor while it is published. Any save by someone who holds Publish — the editor's autosave included — counts as re-confirming the whole item. A save by someone with only Edit content is kept as a change waiting to be released and leaves the clock alone.

The database refuses a change to the last-reviewed date from anyone without Publish, so the clock is only reset by people the agency trusts to vouch for live content.

Some things feel as if they should count, and don't: giving a second approval, assigning a reviewer, or operators acknowledging the item. Two publish paths don't record a review either — a scheduled publish, and Publish in the bulk actions. For an item going live for the first time on a schedule that makes no difference, because its clock runs from the publish date. But an item that was live before keeps any last-reviewed date it already had, so it can land on Review due straight away. And an item bulk-published for the first time gets no publish date, so it has no due date at all — mark it reviewed afterwards to start its clock.

Who is reminded

Once a day the database checks every published item against the policy. For each one past its due date, every active member who holds Publish gets a notification in the bell: "“…” is overdue for re-validation". While the item stays overdue the reminder repeats at most once every 30 days, so an item left alone is raised again roughly monthly until someone marks it reviewed.

Two clocks that share the word "due"

The Review queue (opens the admin console) has deadlines too, and they measure something else entirely:

Because they apply to items in different states, the two never time the same thing at once. An item leaves the review queue when it is published, and that is when its re-validation clock begins.

What this means in practice

• Mark reviewed is a sign-off. Re-check the item before you mark it. The previous date is overwritten, and Review due has no undo; the bulk actions offer only a short one.
• Fixing a typo in a live item re-validates all of it. If you hold Publish, saving a published item restarts its clock whether or not you re-read the rest.
• People without Publish can see Review due but not clear it. Someone who holds Publish has to mark each item reviewed.
• Re-validation happens on the live item. You don't send it back through the review queue, which is for content that isn't live yet.