knowledge-ops

---
name: knowledge-ops
description: Use when authoring or auditing company SOPs, runbooks, or a wiki/knowledge base: 5W2H completeness, orphan/stale page detection, glossary drift, or runbook step verification.
category: Business Operations
version: 1.0.0
tools: []
---

# Knowledge Operations: SOPs, Runbooks, and KB Hygiene

Company SOP and internal runbook authoring, 5W2H completeness validation, and knowledge-base hygiene assessment for Head-of-Ops, Knowledge-Manager, and internal-TPM roles.

## Why this matters

An ops organization a few years in accumulates sprawl — hundreds of wiki pages across Notion, Confluence, Obsidian, shared drives, and a Slack channel that exists because nobody can find the canonical doc. Predictable failure modes recur: no owner (a large share of SOPs name "the team" instead of a person, so nobody is accountable when the doc rots); no last-reviewed date (a years-old SOP references a tool that was sunset long ago); vague success signals (a runbook step says "verify the service is up" — a new operator can't tell what that means); no rollback path (an incident-comms runbook explains how to send an alert but not how to retract a wrong one); orphan pages (no inbound links, findable only if someone already knows the URL); glossary drift (the same acronym means different things in different docs, and new hires guess wrong for months); and happy-path-only SOPs (covering what happens when everything works, not the fraction of cases where it doesn't).

The operator's real question is: which docs to fix first, and what specifically is wrong with each — answered with a deterministic checklist, not intuition.

## When to use

Authoring a new SOP for a cross-functional process (procurement intake, vendor offboarding, incident-comms cascade, employee onboarding, expense reimbursement, customer-escalation playbook, security-incident comms, access provisioning). Validating an existing runbook before it goes into rotation. Auditing a multi-document KB export for orphan pages, staleness, glossary drift, and missing owners. Building the reading list for a new ops hire's first week. Running a quarterly wiki-cleanup sprint.

## Method

1. Assess the KB as a whole. Walk the wiki/vault and extract: a cross-link map (which page references which); glossary candidates (acronyms and proper nouns recurring in 3+ docs without one canonical definition); orphan pages (no inbound links from anywhere); glossary drift (the same term defined or used inconsistently); stale pages (no edit or review in over 12 months — 90 days for regulated content); and missing-owner pages (no named accountable person). Prioritize the cleanup list by staleness times inbound-link-count, so high-traffic stale docs surface first — not by raw page count.
2. Validate each runbook against six required attributes per step: a named owner (not "the team," not "ops"); an expected duration (a concrete number and unit); an observable success signal (e.g. "HTTP 200 from `/healthz`," not "service is up"); an observable failure signal; a rollback path, or an explicit "this step cannot be rolled back, escalate to X"; and a named escalation contact or on-call rotation. Score each step traffic-light (green/amber/red) and the runbook overall 0-100: 80+ is safe to use, 60-79 is use-with-caution, below 60 is not safe to use in an incident.
3. Generate missing SOPs in 5W2H structure: Who (RACI — responsible, accountable, consulted, informed), What (process steps), When (triggers and frequency), Where (system and tool), Why (purpose and regulatory basis), How (step-by-step), How-much (cost and time per execution). A regulated-content profile (SOC 2, HIPAA, ISO 13485, GDPR, SOX) adds version control, a signoff matrix, and an audit trail.
4. Re-audit after the cleanup sprint. The metrics that matter are unfindable docs (orphan count) and unsafe runbooks (validity score below 60) — not raw page count.

## Assumptions

The KB is in markdown or can be exported to it (Notion, Confluence, Obsidian, and Google Docs all support this); HTML-only or PDF-only KBs need a conversion pass first. The user has authority to commission rewrites or archives — a cleanup list nobody acts on is wasted work; route findings to a named owner. Owner metadata lives in explicit frontmatter or a top-of-page "Owner:" line — the person who last edited the page is not treated as the owner. "Stale" defaults to 12 months, shortened to 90 days under a regulated profile. This is organizational knowledge work, not personal note-taking.

## Anti-patterns

Generating SOPs in bulk without owners — a doc with no owner has a half-life of about 6 months; don't generate a batch unless each one is assigned to a named human. Treating a passing validator score as content-correct — the validator catches missing structure, not wrong content; a runbook can score 100 and still tell the operator the wrong thing. Treating all orphan pages as garbage — some orphans are reference pages found only via search; the cleanup list is a priority queue, not a delete list. Letting glossary drift accumulate — two definitions of an acronym become seven within a few years if left unfixed; resolve drift the moment it surfaces. Skipping the regulated profile for regulated workloads — missing version control on a regulated SOP is an audit finding. Hand-writing 5W2H sections from memory — operators reliably forget "How-much"; use the structured scaffold and edit from there.

## Distinct from

Personal knowledge management (one person's interlinked notes) is single-author and informal; knowledge ops is organizational — many authors, many readers, named owners, formal review cycles, compliance overlays. A system-ops runbook for debugging production (logs, alerts, on-call) targets engineers tailing logs; a knowledge-ops runbook targets fellow operators executing a business process (incident-comms cascade, vendor offboarding). Delivery tracking (sprint tickets, project status) tracks who edits a doc; knowledge ops is the content of the doc itself. Process mapping documents the flow of work between stages and finds the bottleneck; knowledge ops documents the artifacts (SOP, runbook, glossary) that operators use to execute that process — both can apply to the same process. Broadcast change-management messaging is the announcement; knowledge ops produces the durable reference artifact behind it. Formal regulatory compliance authoring (a full QMS, technical files, part 820) borrows the same regulatory checklist but is not a substitute for a notified-body audit.

## Canon

5W2H and SOP discipline draw on Kaoru Ishikawa's 5W2H method, Toyota standard-work practice, Atul Gawande's *The Checklist Manifesto*, ISO 9001 documented-information requirements, ITIL v4 Service Operation, and FDA 21 CFR Part 211. Runbook discipline draws on the Google SRE Workbook's runbook chapter, PagerDuty's incident-response taxonomy, the AWS Well-Architected Framework's operational-excellence pillar, and Charity Majors on observability-runbook integration. KB-hygiene anti-patterns draw on wiki research from Notion/Confluence practice, Mozilla's SUMO knowledge-base lessons, and the Atlassian Team Playbook.

## Forcing-question library

Walk one at a time, with a recommended answer and its source, never bundled. Don't open question 4 until 1-3 are locked.

1. Who is the named owner of this SOP or runbook, and do they know they own it? Recommended: a single human, not "the team," who has agreed in writing. (Gawande, *The Checklist Manifesto*, 2009 — checklists without an owner rot within 12 months.)
2. When was this doc last reviewed, and what's the review cadence? Recommended: reviewed within the last 12 months (90 days if regulated), with the cadence written into the doc's metadata. (ISO 9001:2015 §7.5.3 — controlled documents require review-cycle metadata; ITIL v4 echoes this for Service Operation runbooks.)
3. For each runbook step, what is the observable success signal — what specific output tells you it worked? Recommended: a concrete observable ("HTTP 200 from `/healthz`," "Slack thread closed with a done reaction," "opportunity moved to Closed-Won") — not "the service is up." (Beyer et al., *Site Reliability Workbook*, ch. 8, 2018 — vague success criteria are the leading cause of runbook misuse during incidents.)
4. What is the rollback path for each step that can fail? Recommended: every state-mutating step has either a rollback path or an explicit "cannot roll back — escalate to X" line. (AWS Well-Architected Framework, operational-excellence pillar — you cannot run a process you cannot reverse without first agreeing what "reverse" means.)
5. Where does this doc live, and what other docs should link to it? Answering this closes the orphan-page gap the audit will otherwise flag.