Review Cadence Design

Review cadence is the schedule that governs how often each type of content is reviewed for accuracy. A single cadence applied to all content types is a governance mistake: a runbook describing how to respond to a production incident and a decision record from 2023 explaining why the team chose a particular vendor have very different rates of change and very different costs of being wrong.

The cadence should reflect the consequence of stale content and the rate at which the underlying reality changes. High consequence + fast-changing reality = frequent review. Low consequence + slow-changing reality = infrequent review.

1. Monthly Review (Never/Rarely) Monthly review is rarely warranted for knowledge base content — it creates more administrative burden than value. Reserve monthly review for content with both high operational consequence and high change rate: active incident response runbooks during a system migration, sales playbooks during a competitive shift, compliance documentation when regulations are actively changing. Outside of these conditions, monthly review is over-governance.
2. Quarterly Review (Runbooks, FAQs) Procedural content — runbooks, how-to guides, troubleshooting flows — should be reviewed quarterly (every 90 days). Procedures change with system changes, team changes, and tool changes. A runbook that is 91 days old without review may reference a tool that was replaced 3 months ago. FAQ content also changes quarterly as users encounter new questions and old answers become outdated. Quarterly review is the minimum viable cadence for content users take direct action on.
3. Semi-Annual Review (Articles) Explanatory content — articles, concept explanations, architecture documentation — changes more slowly than procedural content. Semi-annual review (every 180 days) catches major accuracy drift without generating excessive review work. The test for whether an article needs more frequent review: if the underlying reality it describes changes faster than every 6 months, move it to quarterly.
4. Annual Review (Decision Records, References) Decision records capture decisions made in a specific context. They do not become inaccurate over time — but they can become superseded or irrelevant. Annual review confirms: is this decision still in effect? Has the context changed enough that the decision should be revisited? Reference content (stable lookup tables, compliance checklists) also warrants annual review. More frequent review of stable content generates reviewer fatigue without adding accuracy value.
5. Event-Triggered Review Beyond scheduled cadences, certain events should trigger immediate review of specific content: a production incident (review incident runbooks), a system migration (review all runbooks that reference the migrated system), a regulatory change (review compliance content), a product launch (review all content referencing the old product version). Event-triggered reviews are not replacements for scheduled reviews — they are supplements that catch changes the schedule would miss.

# Review cadence configuration
content_type_cadences:
  runbook:
    scheduled_days: 90
    event_triggers:
      - "system_migration_affects_this_runbook"
      - "production_incident_of_type_covered_by_this_runbook"
      - "tool_referenced_in_runbook_changed"
    overdue_escalation_days: 14    # Escalate to steward 14 days after due date

  faq:
    scheduled_days: 90
    event_triggers:
      - "question_answered_in_faq_appears_frequently_in_slack"
    overdue_escalation_days: 21

  article:
    scheduled_days: 180
    event_triggers:
      - "major_product_or_service_change_in_domain"
    overdue_escalation_days: 30

  decision_record:
    scheduled_days: 365
    event_triggers:
      - "superseding_decision_made"
      - "context_of_decision_materially_changed"
    overdue_escalation_days: 45

  reference:
    scheduled_days: 365
    event_triggers:
      - "underlying_data_source_updated"
      - "regulatory_or_compliance_change"
    overdue_escalation_days: 45

# Review SLA: reviewer has this many business days to act on a review request
review_sla_business_days: 5

# Notification schedule
notifications:
  advance_notice: 14    # Notify steward and author 14 days before review due
  due_date: 0           # Notify on due date
  overdue: [7, 14]      # Notify again 7 and 14 days overdue before escalation