Knowledge Ops

Knowledge Operations

Knowledge bases do not fail by being incomplete. They fail by becoming untrustworthy: once a

reader has been burned twice by a confidently wrong page, they stop reading and start asking

in chat, and every subsequent doc you write is written into a void. This skill treats the KB

as an operational system with owners, freshness SLAs, and a measurable health score — not as

a writing backlog.

The core insight is that deletion is the highest-value action available. Most struggling

knowledge bases need 30% fewer pages, not more pages.

When to use this skill

• The wiki is large and distrusted — people ask in chat rather than search, and are right to
• A doc audit is due before onboarding a cohort, an acquisition merge, or a compliance review
• Search returns the wrong page consistently, usually because three near-duplicates compete
• Nobody owns large parts of the KB and nobody can say what is current
• Planning a documentation-debt sprint and needing a ranked backlog rather than a wish list
• Migrating between wiki platforms and needing to decide what survives the move

Inputs the skill expects

• A doc inventory: path, title, owner, last-updated date, and outbound links
• Criticality tier per doc, or enough signal (traffic, area) to infer it
• Usage data if available — 90-day views separate the load-bearing pages from the archive
• The as-of date for the audit, so results are reproducible
• Your freshness SLA policy, or acceptance of the default tiering below
• Whether deletion is politically possible, which changes the entire remediation plan

Clarify First

Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] Which docs are load-bearing vs archival — a stale onboarding runbook is an incident; a stale 2019 retro is fine, and treating them identically produces a backlog nobody works
• [ ] Whether pages can be deleted or only archived — deletion authority roughly halves the remediation effort, so the plan differs structurally
• [ ] Who can be assigned as an owner — ownership assigned to a team alias rather than a person is the same as no owner, and the audit will keep reporting it
• [ ] The as-of date for the audit — staleness is relative, and an undated audit cannot be compared against the next one

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Workflows

Workflow 1 — Score KB health

• Build a doc inventory as JSON, or point the auditor at a directory of markdown with

YAML frontmatter (owner, updated, tier).

• Run the auditor with an explicit --as-of date so the run is reproducible.
• Read the health score as a trend, not an absolute. A first run below 60 is normal;

what matters is the direction across quarterly runs.

• Triage the critical findings first — a stale critical-tier doc is the class of failure

that causes real incidents.

python3 business-operations/knowledge-ops/scripts/kb_health_auditor.py \
  --input business-operations/knowledge-ops/assets/sample_kb.json \
  --as-of 2026-07-21 --format text

To scan a real directory of markdown instead:

python3 business-operations/knowledge-ops/scripts/kb_health_auditor.py \
  --root ./docs --as-of 2026-07-21 --format json

Workflow 2 — Find orphans, dead links, and duplicates

• Run the orphan detector over the same inventory. It builds the link graph and reports

pages nothing links to, links pointing at pages that do not exist, and hub pages.

• Cross-reference orphans against traffic. An orphan with traffic is a findability bug

(people reach it by search or bookmark but the IA does not connect it). **An orphan with

no traffic is a deletion candidate.** These need opposite fixes.

• Fix dead links before anything else — they are cheap and they are the most visible

signal of an unmaintained KB.

python3 business-operations/knowledge-ops/scripts/orphan_detector.py \
  --input business-operations/knowledge-ops/assets/sample_kb.json \
  --format text

Workflow 3 — Build a ranked documentation-debt backlog

• Run the debt ranker over the inventory. It scores each issue on value (traffic ×

criticality × severity) and effort, then sorts into do-now / schedule / batch / drop.

• Take the top 10 into a debt sprint. Do not attempt the whole backlog — the backlog is a

measurement instrument, not a plan.

• Re-run the auditor after the sprint with the same --as-of convention to show movement.

python3 business-operations/knowledge-ops/scripts/doc_debt_ranker.py \
  --input business-operations/knowledge-ops/assets/sample_kb.json \
  --as-of 2026-07-21 --top 10 --format text

Decision frameworks

Freshness SLA by tier [PROVEN]

Uniform review cycles fail because they generate more review work than any team will do, so

nothing gets reviewed. Tier the SLA instead.

| Tier | Examples | Review SLA | Stale at | Action when stale |

|------|----------|-----------|----------|-------------------|

| Critical | On-call runbooks, incident procedures, security policy, payroll process | 90 days | 120 days | Page the owner; a stale runbook is an incident risk |

| Core | Onboarding, architecture overviews, team charters, release process | 180 days | 270 days | Owner review ticket in the next sprint |

| Reference | How-tos, tool guides, FAQs | 365 days | 540 days | Batch review annually |

| Archive | Retros, past project docs, historical decisions | Never | Never | Mark archived; exclude from search and from the score |

The single most valuable configuration change in most knowledge bases is moving 40% of pages

into Archive and excluding them from search. Search quality is a ratio, and the denominator is

usually the problem.

Orphan triage [PROVEN]

| Inbound links | 90-day traffic | Diagnosis | Action |

|---------------|----------------|-----------|--------|

| 0 | 0 | Dead weight | Delete. Not archive — delete |

| 0 | Low (1-50) | Bookmark-only survivor | Link it from the right hub, or fold into a parent page |

| 0 | High (50+) | Findability bug | Link from a hub urgently; people are relying on a page the IA hides |

| 1-2 | Any | Weakly connected | Fine if the parent is the right one |

| 10+ | High | Hub page | Protect it; assign a named owner and the Critical SLA |

Duplication resolution [RECOMMENDED]

When two or more pages cover the same topic, merge into the one with the most inbound links,

not the one that is best written. Inbound links represent accumulated navigation habit across

the org; rewriting the winner is cheap, rebuilding link equity is not. Redirect the losers,

never delete them silently — a 404 on a bookmarked page costs more trust than a stale page did.

Escape hatch: if the highest-linked version is factually wrong and the other is correct, merge

into the linked one and replace its content wholesale. The URL wins, the content does not.

Health score bands

| Score | Reading | Response |

|-------|---------|----------|

| 80-100 | Healthy; maintenance mode | Quarterly audit, keep SLAs |

| 60-79 | Degrading; trust still intact | One debt sprint, focus on critical-tier staleness |

| 40-59 | Distrusted; people are asking in chat | Ownership assignment sprint first, then content |

| 0-39 | Failed; a rewrite is cheaper than a repair | Pick the top 20 pages by traffic, rebuild those, archive everything else |

Anti-Patterns

The Documentation Sprint With No Owners

Mistake: Running a week-long effort where everyone writes docs, then declaring the KB fixed.

Why it happens: Writing is visible, satisfying, and easy to organise. Ownership is neither.

Instead: Assign owners before writing anything. An unowned page is stale the day it is

written — it just has not been noticed yet. If you can only do one thing, do ownership

assignment; a KB with owners and old content recovers, and a KB with fresh content and no

owners degrades to the same state within two quarters.

Team Aliases as Owners

Mistake: Setting the owner field to @platform-team or [email protected].

Why it happens: It survives staff turnover and feels more robust than naming a person.

Instead: Name a person, with the team as a fallback field. Review notifications sent to a

group alias are read by nobody — this is the most reliable finding in knowledge-base

operations. Rotate the named owner quarterly if you must, but keep it a person.

Archiving Instead of Deleting

Mistake: Moving every obsolete page to an archive space rather than removing it.

Why it happens: Deletion feels risky and irreversible, and someone always says "we might

need it."

Instead: Delete pages with zero inbound links and zero traffic outright — version history

already preserves them. Archive is for documents with historical or compliance value, not for

things you are afraid to delete. An archive that grows without bound is a slower failure mode

than deletion, not a safer one.

Optimising Search Instead of Fixing Content

Mistake: Responding to "search is broken" by tuning the search engine or buying a new one.

Why it happens: It is a procurement problem with a vendor solution, which is easier than a

content problem with an organisational solution.

Instead: Search almost always fails because three near-duplicate pages compete for the same

query and the engine cannot know which is current. Merge the duplicates and exclude archives

from the index. Do this before evaluating any search product — it is usually the whole fix.

Auditing Without an As-Of Date

Mistake: Running the audit ad hoc and comparing results across runs.

Why it happens: The tooling defaults to "today" and nobody records what today was.

Instead: Always pass an explicit --as-of and store the output. KB health is only

meaningful as a trend; two undated audits cannot be compared, and a number with no trend

gets ignored by the people who fund the remediation.

Files

| File | Purpose |

|------|---------|

| scripts/kb_health_auditor.py | Scores staleness against tiered SLAs, missing owners, duplicate titles, and thin pages |

| scripts/orphan_detector.py | Builds the link graph; reports orphans, dead links, hub pages, and traffic-weighted triage |

| scripts/doc_debt_ranker.py | Ranks remediation work by value and effort into do-now / schedule / batch / drop |

| references/information-architecture-patterns.md | IA models, hub-and-spoke structure, naming, and search-behaviour design |

| references/freshness-sla-and-ownership.md | SLA tiering, ownership models, review workflows, and health metrics |

| assets/kb-audit-report-template.md | Report template for presenting audit findings and a remediation plan |

| assets/doc-ownership-charter.md | Charter defining what a doc owner is accountable for |

| assets/sample_kb.json | Runnable inventory used by all three scripts |