1. Docs
2. Concepts

Reaffirmations

Every adopted catalogue item and accepted decision has a reaffirm-by date, and the chair of the board that owns it states it still holds or marks it for revision — shown on the record itself, in the audit chain, never deleted. A reaffirmation approves nothing.

#Why Reaffirmations

Governance artefacts go stale quietly. A standard adopted last year may no longer match the estate, and a decision accepted two years ago may no longer reflect the technology or the market. Periodic review is a common expectation: ISO 27001 (A.5.1) and COBIT (APO03) both expect policies and standards to be looked at again on a cadence, not only when someone remembers.

Without a date and a named person, "still valid" is an assumption. In Archigov it is a record. Every adopted item has a reaffirm-by date, and the board that adopted it is the one that reaffirms it.

#Not the Same as the Decision Log

A reaffirmation approves nothing:

The Decision Log records what was decided and why. A reaffirmation records that it is still true, and who said so and when. Most items due for reaffirmation are catalogue items, not decisions.

#What Has a Reaffirm-by Date

Nothing else has one:

• drafts, items in review and retired artefacts;
• decisions that are proposed, rejected, superseded or deprecated.

A newly adopted version of an artefact starts again from its own adoption. See Governance catalogue and Decisions.

The cadences are instance settings: review.artefact_months (default 12) and review.decision_months (default 24). The ⓘ beside the Reaffirmations page's title states the values in force.

#How the Date Is Set

• Before any reaffirmation, the reaffirm-by date is the item's adoption date (artefacts) or decision date (decisions), plus the cadence for its kind. A standard adopted on 30 October 2025 is due on 30 October 2026.
• After a reaffirmation, it is the date that reaffirmation set:
  • Reaffirmed — the item still holds. It is next due a full cadence later.
  • Revision needed — the item should change. It comes back for reaffirmation three months later.

Only the latest reaffirmation sets the date. Earlier ones stay as the item's history.

#Status

Every item has a status, worked out from its reaffirm-by date and today:

Revision needed is shown beside the status when the latest reaffirmation asked for a revision. The item still has its three-month date and a status of its own. Statuses are status tags (colour, icon and word) and explain themselves on hover.

#On the Record

The state sits on each record, where people look:

• The decision page has a Reaffirmation section for an accepted decision. It shows:
  • the status, and Revision needed when asked for;
  • Reaffirm by with the date, and the owning board;
  • the cadence;
  • every reaffirmation so far (outcome, by, date, note), or Not reaffirmed yet with the decision date.
• A catalogue item shows the same section in its detail, for adopted items.
• The owning chair gets Reaffirm on the section's header. Everyone else reads the section.
• The Decision Log has a Reaffirm By column. It shows the date alone while in date, and adds the status tag once due soon or overdue. It shows — for decisions not accepted.
• The catalogue list adds Reaffirmation overdue or Revision needed to an item's Status when they apply. Like the rest of that column, it shows only the exceptions.

#Who Reaffirms

Only the chair of the board that owns the item. The owning board is the board the item's review type routes to: an artefact by its kind and category, a decision by its topic (see Routing). In the demo, the standards belong to the Design Authority and POL-001 to the Policy & Compliance Board.

The route admits a reaffirmation for decide_review, and the handler then checks for the chair seat on the owning board. Everyone else is refused with 403:

• the platform admin, a decision maker and the auditor;
• the chair of another board. The Design Authority's chair cannot reaffirm a Policy & Compliance Board policy, and the Policy & Compliance Board's chair cannot reaffirm a Design Authority standard.

See Roles and capabilities.

#In the Work Queue

Items due soon or overdue on the boards a person chairs are in their work queue:

• the Overview's My Work has a Reaffirmations due queue;
• the bell in the header shows Reaffirmation due or Reaffirmation overdue for each item.

Both link to the record itself, where the chair reaffirms it. Items in date are not queued, and nobody else is asked. An item due on the Policy & Compliance Board is in its chair's queue, not the Design Authority chair's.

#The Reaffirmations Page

Governance → Reaffirmations lists every adopted catalogue item and accepted decision, soonest due first. It is the list an auditor asks for. The old address /sign-offs redirects to it.

Filter by Status (Overdue, Due soon, In date or Revision needed) and by Kind (catalogue items or decisions), or search by code or title.

#Reaffirming

Reaffirm opens Reaffirm or Revise for the item. The form says the outcome is recorded under the chair's name in the audit log, and that it does not approve or change the item. It has two fields:

• Outcome — one of:
  • Reaffirm — it still holds; next reaffirmation in 12 months (24 for a decision);
  • Revision needed — it comes back for reaffirmation in three months.
• What needs revising — required for a revision: at least ten characters saying what should change, so an author can draft the revision for the board. A shorter note is flagged on the form, and the button stays disabled until it is long enough. For a reaffirmation the note is optional: anything the next chair to reaffirm it should know.

The primary button names the choice: Reaffirm or Ask for Revision. Reaffirming from a catalogue item steps the item's detail aside for the form, and returns to it afterwards.

#Evidence and Audit

Every reaffirmation is in the audit chain under the chair's name. The Audit Log and the decision's audit trail read it as Reaffirmed or Marked as needing revision. It is recorded on the artefact or decision with its code, the board, the next date and the note. A reaffirmation is never edited or deleted; a new one is a new record.

Governance Metrics shows coverage as a Reaffirmations tile: how many items are not overdue, of all of them, with how many are overdue and due soon. Every board pack carries it in its Coverage table as Items in date for reaffirmation.

In the API, one reaffirmation is a sign-off. That is why the routes are /sign-offs and the audit actions signoff:reaffirmed and signoff:revision_needed.

#Heuristics and AI

Everything that sets a date or a status is deterministic: the adoption or decision date, the cadence, the latest reaffirmation and today.

There is no AI. A reaffirmation is a named person's statement that an item still holds, or does not, and no model proposes an outcome.

#What It Deliberately Does Not Do

• It does not approve anything, and it is not a second Decision Log. Approval is the board's review.
• It does not retire or revise anything by itself. Revision needed is a statement. An author drafts the revision, and a board adopts it through a review; until then the adopted version stays in force.
• It does not let anyone but the owning board's chair reaffirm. Not the platform admin, not a decision maker, not another board's chair.
• It does not let a model propose an outcome.

Note

A reaffirmation shows who stated that an item still holds, and when. Archigov never asserts that a reaffirmed standard or decision meets ISO 27001, COBIT or any other framework: it shows evidence, not assurance.

Something unclear or out of date? Write to hello@archigov.com or open an issue on GitHub.