---
title: "KnowledgeOps"
slug: knowledgeops
category: data
term_status: vendor-specific
evidence_status: verified
summary: "KnowledgeOps is running an organisation's working knowledge (answers, runbooks, procedures) as an operated asset: captured in the flow of work, owned, reviewed in proportion to risk, findable, access-controlled and retired on purpose."
audience: [Beginners, Knowledge managers, Support and operations leads, Technical writers, Platform and AI teams, Leaders]
last_verified: 2026-10-23
key_takeaways:
  - "KnowledgeOps is a vendor-promoted label, not a standard; the established practice behind it is knowledge management, and its most complete method is KCS, renamed Knowledge-Centered Success in 2026."
  - "Capture knowledge while the work happens, in the asker's words; written afterwards, it loses the context that makes it findable."
  - "Every live item needs an owner who still works here, a state and an audience. Without owners, documents go stale."
  - "Match review to risk: frequently used answers are reviewed by reuse; rare, high-consequence runbooks need calendar review and rehearsal."
  - "Set goals on outcomes (link accuracy, freshness of critical items, self-service success), never on activity counts such as articles written."
  - "An AI assistant turns a stale or over-shared article into a confident, wide answer: carry state, version and audience into every index."
related: [supportops, contentops, llmops, itops, chatops, incidentops, privacyops, sre]
---

## What KnowledgeOps is

### KnowledgeOps in 30 seconds

**KnowledgeOps** is running an organisation's working knowledge (answers to recurring questions, troubleshooting articles,
runbooks, procedures) as an *operated asset*: captured while the work happens; owned, with a state and an audience; reviewed in
proportion to risk; findable by people and AI assistants in their own words; and retired on purpose rather than left to rot.

A useful test: a new engineer hitting a known problem at 03:00 finds a current, validated answer in a minute, instead of
waiting for the one person who knows or picking the wrong one of three conflicting pages.

::: note Honest term status
"KnowledgeOps" is **not** a standard, a recognised discipline or a job family. ScreenSteps says it "coined the term for Knowledge
Ops in business"[^ss-blog], but a 2021 session by Pryon, an AI vendor, already presented "knowledge ops" as a
methodology[^kmworld-2021]; Knowmax[^knowmax] and DeemL[^deeml] publish their own definitions. We class it as
**vendor-specific**: several vendors use it, every use we found promotes a product, and no neutral body defines it. The practice
underneath is **established**: knowledge management, with an ISO standard (ISO 30401)[^iso30401], and Knowledge-Centered
Service, now Knowledge-Centered Success (KCS), from the non-profit Consortium for Service Innovation[^kcs-new]. This page teaches
that practice, with an operations emphasis.
:::

**Where to start.** Beginners: [glossary](#glossary-and-mental-model), [Lab 1](#hands-on-labs). Practitioners:
[playbooks](#core-practices-and-playbooks), [reference implementation](#reference-implementation). Leaders:
[decision framework](#decision-framework), [judgement call](#a-judgement-call-index-everything-or-start-from-an-allowlist).
**Last verified** 2026-10-23.

### At a glance

| Aspect | Summary |
|---|---|
| Goal | People (and assistants) find correct, current answers without interrupting experts |
| Who | Knowledge managers, support and operations leads, writers, runbook owners, AI teams |
| Prerequisites | None; a ticketing or incident system makes reuse measurable |
| In scope | KCS, knowledge bases and wikis, tacit knowledge, docs as code, ownership and review, findability and taxonomy, runbook reuse, knowledge metrics, the corpus behind AI search |
| Out of scope | Editorial content programmes ([ContentOps](../contentops/)); the self-service channel and deflection ([SupportOps](../supportops/)); retrieval engineering ([LLMOps](../llmops/)); knowledge records inside ITSM tooling ([ITOps](../itops/)) |
| Outputs | Metadata contract, owner register, tiered review policy, article lifecycle, monthly scorecard |
| Term status | Vendor-specific label; established practice (box above) |

### The problem it solves

Without an operating model, knowledge fails in five ways:

- **It stays in heads.** Experts answer the same question again and again. In the professional-developer section of Stack
  Overflow's 2024 survey, "61% of all respondents spend more than 30 minutes a day searching for answers or solutions to
  problems", including asking colleagues and waiting[^so-2024].
- **It is written but not owned.** On Google's early internal wiki, "Because there were no true owners for documents, many became
  obsolete"[^swe-docs].
- **It is owned but not findable.** The answer uses the author's vocabulary, not the asker's.
- **It is missing exactly when it matters.** GitLab's 2017 outage report notes that a key `pg_basebackup` behaviour "was not
  clearly documented in our engineering runbooks"[^gitlab-2017]; Atlassian's 2022 review: "We have playbooks for product-level
  incidents, but not for the events of this scale"[^atlassian-pir].
- **It leaks or misleads at machine speed.** An AI assistant repeats whatever is stale and shows whatever its index can reach.

**What good looks like.** Google's SRE book reports that a playbook written ahead of time "produces roughly a 3x improvement in
MTTR as compared to the strategy of 'winging it'" (MTTR: mean time to repair)[^sre-intro], one company's experience. Consortium
members report "50 - 60% improved time to resolution" after adopting KCS[^kcs-why], self-reported, so a ceiling to test, not a
forecast.

### What KnowledgeOps is not: boundaries and naming

- **Not a product category.** Buying a knowledge base does not create owners, states or review habits.
- **Not ContentOps.** The split is by **origin**, an **editorial distinction** shared with that page: knowledge captured while
  solving cases or running operations (KCS articles, runbooks) is KnowledgeOps, even when published to customers; editorially
  planned content is [ContentOps](../contentops/).
- **Not retrieval engineering or the self-service channel.** KnowledgeOps owns what goes *into* a corpus or help centre (versions,
  states, access labels); [LLMOps](../llmops/) and [SupportOps](../supportops/) own what happens next.
- **Not AI-agent memory.** An agent skill named "knowledge ops" syncs files, memory stores and Git repositories[^skill], a
  different sense of the words.

## Where it comes from and where it sits

### Origins and evolution

The label is recent; the practice is not.

- **Tacit knowledge.** Polanyi's "we can know more than we can tell" (1966) and Nonaka and Takeuchi's SECI model of converting
  tacit to explicit knowledge (1995) are the usual intellectual roots[^tacit].
- **KCS** rests on "more than thirty years of Consortium Member experience with KCS", mainly in support[^kcs-new]. In April 2026
  the Consortium announced Knowledge-Centered Success: a new name, a Solve Loop that begins with Reuse, a "proficiency model"
  instead of the "licensing model", and no version number for the method; v6 certifications remain valid[^kcs-whatsnew][^kcs-cert].
- **Standards.** ISO 30401:2018 (amended 2022 and 2024) sets requirements for knowledge management systems; its revision,
  ISO/DIS 30401, closed its DIS ballot (stage 40.60) on 2026-09-18, so a new edition may
  follow[^iso30401][^iso-proj].
- **The vendor label.** V. Mary Abraham's notes on a KMWorld Connect 2021 session (2021-11-16) have Pryon's chief
  executive discussing "knowledge ops, an AI-enabled, process-oriented methodology"[^kmworld-2021]. ScreenSteps'
  Greg DeVore wrote in 2023: "Instead of calling it just a knowledge base we refer to it as a knowledge operations
  platform"[^ss-devore]; ScreenSteps' coinage claim is its own, and the 2021 use predates the earliest ScreenSteps use we found.
  Knowmax wrote "KnowledgeOps" as one word in August 2026[^knowmax].
- **AI assistants** made freshness and access control a security concern[^owasp-llm08].

### Glossary and mental model

| Term | Meaning | Example |
|---|---|---|
| Knowledge item | One reusable answer: article, runbook, procedure | "VPN drops every 10 minutes on macOS 15" |
| Solve Loop | KCS: what responders do on each request (reuse, improve, capture, structure)[^kcs-solve] | Link the article that solved the ticket |
| Evolve Loop | KCS: organisation-level analysis improving content, workflow and products[^kcs-evolve] | Monthly review of top-linked articles |
| Article state | KCS: confidence, audience and governance[^kcs-state] | Validated, Internal, Experience-based |
| Link, reuse | Associating a ticket or incident with the article that resolved it[^kcs-link] | Ticket T-1042 → KB-310 |
| Reuse is review | Whoever uses an article fixes or flags it then[^kcs-reuse-review] | Add the missing macOS version |
| Owner, verifier | The accountable person or group[^guru-verify][^zendesk-verify] | `owner: payments-oncall` |
| Freshness date | Last time an owner confirmed the item[^swe-docs] | `last_reviewed: 2026-09-20` |
| Taxonomy | Preferred and alternative labels, as in W3C SKOS[^skos] | prefLabel "VPN", altLabel "remote access" |

**Mental model: knowledge is inventory that spoils.** Each item has a *carrying cost* (someone must keep it true), a *shelf life*
(its systems change) and a *blast radius* (the harm a wrong copy does). Stock what is demanded, rotate what spoils, label what is
hazardous, and discard deliberately.


::: figure KnowledgeOps and its neighbours: who owns which part of knowledge
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 150, "nodeSpacing": 18, "rankSpacing": 34, "padding": 8}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  SRC["Where knowledge is born: tickets, incidents, chat answers, changes"]:::neutral
  KO["KnowledgeOps: capture, owners, states, review, findability, retirement"]:::core
  SRC --> KO
  subgraph USE["Who consumes it"]
    direction LR
    SUP["SupportOps: help centre, bots, deflection"]:::neutral
    LLM["LLMOps: retrieval, evaluation"]:::neutral
    INC["IncidentOps and SRE: runbooks in use"]:::neutral
  end
  subgraph RULES["Who sets adjacent rules"]
    direction LR
    CON["ContentOps: editorial content, same owner rules"]:::neutral
    PRI["PrivacyOps: deletion duties"]:::neutral
    ITO["ITOps: articles inside ITSM records"]:::neutral
  end
  KO --> USE
  RULES -.-> KO
```
Text equivalent: Knowledge born in tickets, incidents, chat answers and changes becomes owned, reviewed, findable items in
KnowledgeOps, which also retires them. SupportOps (help centre, bots, deflection), LLMOps (retrieval, evaluation) and IncidentOps
with SRE (runbooks) consume them. ContentOps, PrivacyOps (deletion duties) and ITOps (ITSM records) set adjacent rules.
:::

### How KnowledgeOps relates to other Ops

These boundaries are this Atlas's **editorial distinctions**.

| Neighbour | Shared ground | Choose that page when... |
|---|---|---|
| [SupportOps](../supportops/) | Articles used on tickets | You design the help centre, bots or deflection |
| [ContentOps](../contentops/) | Owners, review dates | The text is planned editorially |
| [LLMOps](../llmops/), [FinOps for AI](../finops-for-ai/) | The corpus behind an assistant | You tune retrieval or model AI and re-indexing spend |
| [ITOps](../itops/) | Knowledge in incident and problem records | You configure the ITSM tool's article links |
| [ChatOps](../chatops/) | Answers given in chat | You run the chat interface itself |
| [IncidentOps](../incidentops/), [SRE](../sre/) | Runbooks and postmortems | You run incident response or define reliability practice |
| [PrivacyOps](../privacyops/) | Personal data in articles and indexes | You decide the legal basis or handle erasure requests |
| [PeopleOps](../peopleops/), [EduOps](../eduops/) | Onboarding knowledge | You run the learning programme or deliver training |
| [DecisionOps](../decisionops/) | Rules and policies that people also look up | You version, test and audit automated decision logic |

## Principles and operating model

### Charter and principles

No official KnowledgeOps manifesto exists; ScreenSteps publishes its own principles, such as "Performance First"[^ss-help]. What
follows is **this Atlas's proposal**, built mostly on KCS and Google's documentation practice.

::: decision Proposed charter (Atlas proposal, not an industry standard)
**Mission.** Anyone who meets a known problem finds a correct, current answer, in their own words, faster than a person to ask.
**Goals to calibrate:** link accuracy ≥ 90 %; tier-1 runbooks reviewed within 90 days and rehearsed twice a year; no live item
without an active owner; no assistant answers from archived or wider-audience content. **Non-goals:** writing everything down;
article counts; editorial publishing; running the search engine.
:::

1. **Capture in the flow of work.** KCS: "If we are creating articles after the request is resolved, we have missed vital
   information"[^kcs-capture].
2. **Write in the asker's words.** The issue statement records "the requestor's view of what is happening"[^kcs-article]; insider
   terms become alternative labels.
3. **Every live item has a current owner.** "Documents without owners become stale and difficult to maintain"[^swe-docs].
4. **Review follows risk.** Reuse reviews what is used; rare, critical items need dates and rehearsal.
5. **Goals on outcomes, never on activities.** KCS says it in capitals: "DO NOT PUT GOALS ON ACTIVITIES!"[^kcs-metrics]
6. **Access travels with the item.** Audience labels are enforced in every copy and index.
7. **Retire deliberately.** Archive linked items, delete wrong unlinked ones, and always remove them from retrieval.

**Trade-offs.** Capture in the flow and coaching cost capacity while people learn[^kcs-roi]; collective editing trades polish for
speed; strict ownership adds a hand-off when people move.

### Fundamentals and building blocks

- **The knowledge item.** KCS articles hold issue, environment, resolution and cause, plus metadata such as state, dates and use
  counts[^kcs-article].
- **A metadata contract**, checked by machine ([reference implementation](#reference-implementation)).
- **Ownership**: a person or group per item or domain, synced with the people directory.
- **A review policy by tier** (table below).
- **Findability**: the asker's vocabulary, a light taxonomy (preferred and alternative labels, broader and narrower terms in
  SKOS[^skos]) and failed-search analytics.
- **Feedback**: links, flags, search logs and assistant feedback, reviewed in the Evolve Loop.

The tiers are **this Atlas's proposal**, encoded in the metadata `tier` field; governance uses KCS's "Experience Based" and
"Compliance Based" values[^kcs-state].

| Tier | What it covers | Review engine | Governance |
|---|---|---|---|
| 1, rare and critical | Disaster recovery, restores, security incident steps, regulated procedures | Owner review every 90 days and on dependent change; rehearsal twice a year | Compliance-based: named editors |
| 2, periodic or harmful but used | Payroll cut-off, quarterly close; harmful items used at least monthly | Review on dependent change, 180-day backstop; reuse covers the rest | Owner approves edits |
| 3, frequently reused | Troubleshooting and how-to answers | Reuse is review; no calendar | Experience-based |

::: caution A deliberate departure from KCS
KCS is demand-driven: "If we are reviewing articles in absence of demand, we are not doing KCS", with exceptions only for coaching
and domain experts' Evolve Loop analysis[^kcs-state]. Calendar review (tiers 1 and 2) and rehearsal (tier 1) are **this Atlas's
departure**: a disaster-recovery runbook has almost no demand until the day it must work, so demand cannot review it
([use case B](#use-cases-and-scenarios)).
:::

### Roles, ownership and RACI

KCS has proficiency levels (Candidate, Contributor, Publisher), Coaches, Knowledge Domain Experts and a KCS Council; a coach looks
after five to eight people at first and about fifty when mature[^kcs-roles]. Runbooks and AI add operational roles:

| Activity | Knowledge worker | Item owner | Domain expert (KDE) | KnowledgeOps lead | Security / privacy |
|---|---|---|---|---|---|
| Capture, link, flag or fix while working | R/A | I | — | — | — |
| Validate and publish externally | R/A (Publisher) | C | C | I | — |
| Tier-1 runbook review and rehearsal | C | R/A | C | I | C |
| Domain analysis: gaps, duplicates, root causes | C | C | R/A | C | — |
| Metadata contract, review policy, scorecard | I | C | C | R/A | C |
| Audience labels on items fed to assistants | I | R | C | A | C |
| Erasure requests touching items or indexes | — | R | — | C | A |

R = responsible, A = accountable, C = consulted, I = informed. Proficiency is "not linked or related to the levels, job roles, or
positions in an organization"[^kcs-roles], so a senior engineer can be a Candidate.

### Article lifecycle

KCS defines confidence states from Work in Progress to Archived; an article can move "from the Not Validated to Validated
qualities several times throughout its life cycle"[^kcs-state]. Operations adds a **flagged** state and **removal from every
index** on archiving.

::: figure Life of one knowledge item, with the states that matter to operations
```mermaid
stateDiagram-v2
  direction TB
  [*] --> WIP: issue captured, no answer yet
  WIP --> NotValidated: answer found, low confidence
  WIP --> Validated: answer confirmed, meets standard
  WIP --> [*]: nothing reusable, deleted
  NotValidated --> Validated: reused and confirmed
  Validated --> Flagged: a user finds it wrong
  NotValidated --> Flagged: a user finds it wrong
  Flagged --> Validated: owner fixes it
  Validated --> Archived: obsolete; removed from search and indexes
  NotValidated --> Archived: obsolete
  Archived --> Validated: restored
```
Text equivalent: An item starts as Work in Progress when an issue is captured without an answer. It becomes Not Validated when an
answer exists with low confidence, or Validated when confirmed and up to standard; a WIP with nothing reusable is deleted. Reuse
can promote Not Validated to Validated. Any user can flag a Validated or Not Validated item, and the owner fixes it. Any obsolete
live item is archived, which removes it from search and every index; an archived item can be restored.
:::

KCS argues for speed: "the value of support knowledge begins to diminish 30 days after the issue is first
discovered"[^kcs-state], a claim from members' experience, not a measured constant.


### Operating model and governance

| Cadence | Activity | Owner |
|---|---|---|
| Every request | Search early; link; flag it or fix it; capture if missing[^kcs-solve] | Knowledge worker |
| Weekly | Triage flags and WIPs; read failed searches and "no answer" logs | Domain experts |
| Fortnightly | KCS Council ("a bi-weekly basis"[^kcs-roles]): standard, workflow, tools | KnowledgeOps lead |
| Monthly | Checklist sampling (weekly during rollout[^kcs-health]); scorecard; owner hygiene | Coaches, lead |
| Quarterly | Tier-1 review audit; top-linked domain analysis; audience-label audit of indexes | KDEs, security |
| Twice a year | Rehearse tier-1 runbooks in a game day | Item owners with [IncidentOps](../incidentops/) |

Escalation: an article that "poses an active risk of harming customers" goes to a Coach or domain expert at once, who
unpublishes or archives it[^kcs-state].

## Architecture and workflow

### Reference architecture

The essential idea: **one system of record per item**, a machine-readable metadata contract, and every downstream copy treated as
a derived view that can be reconciled against the record.

::: figure Reference architecture: the system of record and its derived views
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 16, "rankSpacing": 30, "padding": 8}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  subgraph WORK["Systems where work happens"]
    direction LR
    TK["Tickets and incidents"]:::neutral
    CH["Chat"]:::neutral
    RP["Code repositories"]:::neutral
  end
  KB["System of record: knowledge base or docs repo; items with owner, tier, state, audience, version"]:::core
  REG["Owner register synced with the people directory"]:::core
  subgraph VIEWS["Derived views, rebuilt from the record"]
    direction LR
    SE["Search with synonyms"]:::neutral
    HC["Help centre for customers"]:::neutral
    AI["AI index: chunks keep id, version, audience"]:::risk
  end
  FB["Feedback: links, flags, failed searches, assistant logs"]:::neutral
  WORK -->|"capture, link"| KB
  REG --> KB
  KB --> VIEWS
  VIEWS --> FB
  FB -->|"Evolve Loop"| KB
```
Text equivalent: Tickets, incidents, chat and code repositories feed the system of record, which holds each item with owner, tier,
state, audience and version; an owner register synced with the directory keeps owners valid. Search, the help centre and an AI
index (red: errors there spread fastest) are rebuilt from the record. Links, flags, failed searches and assistant logs flow back
through the Evolve Loop.
:::

| Component | Control |
|---|---|
| System of record | The only editable copy; edits by role and governance class; version history |
| Owner register | Synced from the directory; leavers trigger reassignment |
| Help centre | Only items with an external audience; KCS Publisher rights[^kcs-license] |
| AI index | Built only from allowed states and audiences; reconciled on every build ([Lab 3](#lab-3-advanced-gate-an-ai-index-build)) |


**Alternatives.** Docs as code suits runbooks; a knowledge-base product suits support, with ticket links and external audiences.
Many organisations run both and federate search; KCS accepts links to non-KCS content that is maintained, findable, accessible
and in context[^kcs-link].

### End-to-end workflow

The KCS double loop: the Solve Loop runs inside each request, the Evolve Loop over many.

::: figure One request through the Solve Loop, and what the Evolve Loop learns from many
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 130, "nodeSpacing": 16, "rankSpacing": 28, "padding": 8}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  R["Request arrives; search in the asker's words"]:::core
  F{{"Relevant item found?"}}:::decision
  OK{{"Does it work as written?"}}:::decision
  L["Link it; add missing symptoms"]:::core
  FX["Fix it, or flag it if not allowed to edit"]:::risk
  W["Create a WIP item from the search terms"]:::neutral
  S["Solve; complete the item; set state"]:::core
  E["Evolve Loop: top links, gaps, duplicates, root causes"]:::neutral
  R --> F
  F -->|"yes"| OK
  F -->|"no"| W --> S
  OK -->|"yes"| L
  OK -->|"no"| FX --> L
  L --> E
  S --> E
```
Text equivalent: The responder searches in the asker's words. A working item is linked and gains missing symptoms; one that fails
is fixed or flagged, then linked. With no item, the responder creates a Work in Progress item from the search terms, solves the
problem and completes it. Links and new items feed the Evolve Loop: top links, gaps, duplicates, root causes.

:::

| Decision | Owner | Recorded in |
|---|---|---|
| Item linked as "resolved" or "referenced" (optional link types) | Knowledge worker | Ticket link field[^kcs-v6-link] |
| State Validated, audience external | KCS Publisher | Item metadata[^kcs-license] |
| Tier-1 change approved | Item owner | Pull request review |
| Item archived and de-indexed | KDE or owner | Item metadata; index build log |

## Practices, frameworks and tools

### Core practices and playbooks

| Practice | Trigger | Owner | Output | Verification |
|---|---|---|---|---|
| Search early, search often[^kcs-solve] | Every request | Knowledge worker | Search terms kept as context | Tickets with a search logged |
| Link what you used | Ticket or incident closed | Knowledge worker | Link marked resolved or referenced | Link rate; sampled link accuracy |
| Flag it or fix it[^kcs-solve] | Item found wrong or incomplete | Whoever found it | Edit or flag with reason | Flag age; repeat flags per item |
| Capture on demand | No item found | Knowledge worker | WIP item in the asker's words | WIPs open more than 30 days |
| Tier-1 review and rehearsal | Review date, dependent change, game day | Item owner | Confirmed or corrected runbook | Freshness; rehearsal findings |
| Owner hygiene | Leaver or team change | KnowledgeOps lead | Items reassigned | Ownerless ratio |
| Retire | Obsolete or duplicate | KDE | Archived item, de-indexed | Archived items still retrievable (0) |

**Playbook: turning an incident into a runbook.** Every incident review gets one knowledge action: create or fix the runbook that
would have shortened it (trigger in the responders' words, ordered checks, decision points, rollback), with a tier, an on-call
owner and a rehearsal. Follow-up tracking is on [IncidentOps](../incidentops/).

**Playbook: a duplicate cluster.** The KDE picks the best item as canonical, merges unique symptoms and environments into it,
archives the others (still viewable from linked tickets) and adds "see also" pointers. KCS treats uniqueness as "a critical part"
of its content checklist[^kcs-health].

### Tacit knowledge: capture and retention

Some knowledge cannot be fully written down[^tacit]. Google: "Tribal knowledge exists in the gap between what individual team
members know and what is documented"; the two "complement each other", and the danger is a single point of failure, "A
bottleneck that occurs when critical information is available from only a single person"[^swe-share].

| Technique | How tacit knowledge moves | Output | Basis |
|---|---|---|---|
| Capture in the flow | Item written from the question while the expert works | Item in the asker's words | KCS[^kcs-capture] |
| Pairing and swarming | Two people solve real work together | A second capable person | Pairing "prevents silos of knowledge"[^pairing] |
| Walk-through interview | A peer has the expert narrate a real task, then writes it up | Draft runbook, Not Validated | Atlas practice |
| Community of practice | Practitioners "learn how to do it better as they interact regularly"[^cop] | Answers; who knows what | Wenger-Trayner |
| Incident reviews | Ask "what did we know that was not written down?" | Knowledge actions | [SRE](../sre/) postmortems |

**Playbook: an expert is leaving (Atlas proposal).** *Trigger:* a resignation or role change, or an audit showing one person owns
many tier-1 items. *Owner:* the expert's manager, with the KnowledgeOps lead. *Steps, within the notice period:* (1) list the
items they own and the questions only they answer (tickets and chat where they responded); (2) reassign every item; (3) run
walk-through interviews for tier-1 and tier-2 procedures, written up by the successor so gaps show; (4) pair the successor on real
work; (5) have the successor rehearse each tier-1 procedure. *Output:* a handover list, rewritten items (Not Validated until
reused or rehearsed), a successor per domain. *Acceptance:* no live item owned by the leaver; every tier-1 item rehearsed by its
new owner.

**When knowledge should stay tacit.** Fast-changing judgement and design taste spread more cheaply by pairing, rotation and
swarming than by documents. Then the job is to record *who* knows and to stop single points of failure forming[^swe-share].


### Methods, standards and frameworks

| Framework (kind) | What it gives you | Status |
|---|---|---|
| KCS (Knowledge-Centered Success; v6 still widely used): method, Consortium for Service Innovation | Double loop, article states, roles, measures | Practice guidance; certification by the Consortium, "the only authorized certifying body for KCS"[^kcs-cert] |
| ISO 30401: international standard | Requirements for a knowledge management *system* | Normative if you seek conformity; revision under way ([origins](#origins-and-evolution))[^iso-proj] |
| Docs as code: practice | Version control, plain text, review, automated tests for docs[^wtd] | Industry practice |
| Diátaxis: documentation framework by Daniele Procida | Four forms: tutorials, how-to guides, reference, explanation[^diataxis] | Optional; good for engineering docs |
| W3C SKOS: Recommendation, 2009 | Data model for taxonomies and thesauri[^skos] | Stable standard; optional |


**Mandatory versus optional.** None is mandatory unless a contract, certification or regulation requires it; regulated
document-control rules set review periods for compliance-based items. KCS says ITIL "is a framework, not a methodology" and that KCS "plugs in" to it, especially incident management[^kcs-itil].

### Tooling landscape

| Category | Job | Examples (verified on 2026-10-23) | Selection criteria |
|---|---|---|---|
| Knowledge base with verification | Owners, review intervals, reminders | Zendesk: weekly rules mark articles unverified; Enterprise plans only[^zendesk-verify]. Guru: a verifier per card, weekly to yearly or dated review[^guru-verify] | Ticket linking; states and audiences; metadata export |
| Docs as code | Runbooks and engineering docs next to code | Git with CODEOWNERS[^codeowners]; Backstage TechDocs, "docs-like-code" in a developer portal[^techdocs] | Review workflow; ownership in files; build checks |
| Quality checks | Lint prose, check links, check metadata | Vale, "code-like linting to prose"[^vale]; lychee link checker, exit code 2 on link failures[^lychee] | Runs in CI; low false positives |
| Search and AI assistants | Retrieve answers | Microsoft Copilot "only surfaces organizational data to which individual users have at least view permissions"[^copilot] | Permission trimming; citations; deletion propagation |
| KCS tool designations | Evidence that a tool supports KCS | The Consortium's KCS Verified and Aligned designations[^kcs-new] | Use as a shortlist filter, not proof of fit |

**Lock-in.** Knowledge bases keep links, states and analytics in proprietary schemas: insist on exporting items *with* metadata
and links, and test an export yearly.


### Automation and AI

Automate the crisp rules (overdue reviews, ownerless items, broken links, missing metadata, archived items still indexed) in
scheduled jobs ([Lab 1](#lab-1-beginner-audit-owners-and-review-dates)). AI changes two things:

1. **Drafting.** A draft from a ticket or incident timeline stays Not Validated until a proficient person confirms it.
2. **Retrieval.** An assistant answers fluently from whatever its index holds. Four controls follow:
   - **Permission-aware retrieval.** OWASP calls for "permission-aware vector and embedding stores"[^owasp-llm08]; Microsoft
     tells customers to ensure "the right users or groups have the right access to the right content"[^copilot].
   - **Freshness and deletion.** Index updates must meet compliance requirements "such as *right to be forgotten*
     requests"[^ms-genaiops]. Archiving is not enough until the index is rebuilt.
   - **Trusted sources only.** OWASP: "Accept data only from trusted and verified sources"[^owasp-llm08], hence a corpus allowlist.
   - **Checkable claims.** Anthropic's guidance has the model cite a quote per claim and retract unsupported ones[^anthropic-halluc];
     that needs chunk IDs that map to stable item IDs and versions.

Retrieval tuning is on [LLMOps](../llmops/); re-embedding cost on [FinOps for AI](../finops-for-ai/).

## KnowledgeOps in practice

### Reference implementation

A docs-as-code implementation for runbooks and procedures in one Git repository; a knowledge-base product follows the same
contract through its API. Assumptions: GitHub, Markdown items with front matter, Python 3.8 or later on the runner.

**1. The metadata contract.** Every item's front matter carries these fields. The Lab 1 audit enforces the first five; its
stdlib parser reads flat `key: value` lines and drops `#` comments; production code should use a YAML library.

_Example status: YAML syntax-checked by the validator, and parsed by the Lab 1 audit on 2026-10-23; field names are this Atlas's
proposal._

```yaml
id: KB-105                  # stable; never reused, survives renames
owner: payments-oncall      # a person or group in the directory
tier: 1                     # 1 rare and critical, 2 periodic, 3 reused
state: validated            # wip, not_validated, validated, archived
last_reviewed: 2026-09-20   # set by the owner, in review
version: 7                  # incremented on every published change
audience: internal          # public, customers, internal, restricted
governance: compliance      # experience or compliance (KCS terms)
supersedes: [KB-071]        # items this one replaced
```

**2. Ownership in the repository.** CODEOWNERS requests review from owners when their files change; the last matching pattern
wins. It works in public repositories on GitHub Free and in private ones on paid plans[^codeowners]. Owner review is real only
when "Require review from Code Owners" is enabled, owners (including teams) have write permission, and administrators cannot
bypass the rule ("Do not allow bypassing the above settings")[^codeowners][^gh-protected]. GitHub adds that "you also need to
define an owner for the CODEOWNERS file itself"[^codeowners]; `/.github/` covers it and the workflow.

_Example status: format checked against GitHub's documentation; not executed._

```text
# .github/CODEOWNERS  (last match wins)
*                         @example-org/knowledge-leads
/runbooks/payments/       @example-org/payments-oncall
/runbooks/dr/             @example-org/sre-dr
/procedures/payroll/      @example-org/payroll-ops
/.github/                 @example-org/knowledge-leads
```

**3. Scheduled checks.** Two independent weekly jobs: the audit and a link check. They are separate because the audit normally
fails (its findings are the worklist), and a later step in the same job would be skipped under the default `success()` status
check[^gha-expr]. Scheduled workflows run in UTC by default, on "the latest commit on the default branch", and public repositories disable
them after 60 days without activity[^gha-schedule]. The lychee action fails its job on broken links by default[^lychee-action].

_Example status: YAML syntax-checked; action versions are the latest releases on 2026-10-23 (checkout v7.0.1, lychee-action
v2.9.0); not executed. `kb_audit.py` is the Lab 1 script; the directory URL is a placeholder._

```yaml
name: knowledge-health
on:
  schedule:
    - cron: "30 6 * * 1"        # Mondays 06:30 UTC
  workflow_dispatch: {}
permissions:
  contents: read
jobs:
  audit:
    runs-on: ubuntu-latest
    environment: directory-read  # the only place the directory token lives
    steps:
      - uses: actions/checkout@v7.0.1
      - name: Fetch active people and groups (never committed)
        env:
          DIRECTORY_TOKEN: ${{ secrets.DIRECTORY_READ_TOKEN }}
        run: >-
          curl -fsS -H "Authorization: Bearer $DIRECTORY_TOKEN"
          -o "$RUNNER_TEMP/roster.txt"
          https://directory.example.com/api/active-handles
      - name: Owners, tiers and review dates
        run: >-
          python3 tools/kb_audit.py "$RUNNER_TEMP/roster.txt" "$(date -u +%F)"
          runbooks procedures
  links:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7.0.1
      - uses: lycheeverse/lychee-action@v2.9.0
        with:
          args: --no-progress 'runbooks/**/*.md' 'procedures/**/*.md'
```

**Design notes.** The roster is fetched at run time into the runner's temporary directory, so no staff list is committed for
repository readers. The read-only token is a secret of the `directory-read` environment; environment secrets reach only jobs
that reference the environment[^gh-envs], so the `links` job never sees it. Limit the environment's deployment branches to the
default branch, so other branches' workflows cannot use it (in private repositories, environment secrets and deployment branches need a paid plan), and clear "Allow
administrators to bypass configured protection rules", which is on by default (Free, Pro and Team plans offer that switch only
for public repositories)[^gh-envs]. Administrators can still reconfigure the environment[^gh-envs-manage], so count them among
the token's readers. Run logs name
departed owners and are readable by anyone with read access[^gh-logs]. An empty audit exits 2, so a wrong path fails loudly. It
is not a pull-request check, which would block authors for others' overdue items. Pin actions to commit SHAs if policy requires.

### Hands-on labs

Three labs, runnable on a laptop with Python 3.7 or later and no network, on invented data. **All three were executed on
2026-10-23 with Python 3.8.10 (Lab 1 again after its revision); the outputs shown are the real outputs.**

#### Lab 1 (beginner): audit owners and review dates

**Objective.** Find items with missing metadata, departed owners or overdue reviews under the
[tier policy](#fundamentals-and-building-blocks). **Prerequisites.** Python 3.7+, Bash. **Cost and risk.** None; it reads files
only. **Steps.** Save the script as `kb_audit.py`, then run the generator: it creates seven items in nested folders (the
CODEOWNERS layout above) and a roster, and audits them as of 2026-10-23.

_Example status: executed on 2026-10-23 (Python 3.8.10)._

```python
"""Audit owners and review dates in Markdown knowledge items (stdlib only)."""
import re
import sys
from datetime import date
from pathlib import Path

REQUIRED = ["id", "owner", "tier", "state", "last_reviewed"]
WINDOW_DAYS = {"1": 90, "2": 180, "3": None}  # tier 3: reviewed on reuse only


def front_matter(path):
    """Flat 'key: value' lines between --- fences; '  # comments' dropped."""
    lines = path.read_text(encoding="utf-8").splitlines()
    if not lines or lines[0].strip() != "---":
        return {}
    meta = {}
    for line in lines[1:]:
        if line.strip() == "---":
            break
        key, sep, value = re.sub(r"\s+#.*$", "", line).partition(":")
        if sep:
            meta[key.strip()] = value.strip().strip('"')
    return meta


def check(meta, active, today):
    if meta["owner"] not in active:
        yield "owner not active: " + meta["owner"]
    if meta["tier"] not in WINDOW_DAYS:
        yield "unknown tier: " + meta["tier"]
        return
    try:
        age = (today - date.fromisoformat(meta["last_reviewed"])).days
    except ValueError:
        yield "bad date: " + meta["last_reviewed"]
        return
    window = WINDOW_DAYS[meta["tier"]]
    if window is not None and age > window:
        yield "tier %s overdue by %d days" % (meta["tier"], age - window)


def audit(dirs, roster_file, today):
    active = set(Path(roster_file).read_text(encoding="utf-8").split())
    findings, live = [], 0
    for path in sorted(p for d in dirs for p in Path(d).rglob("*.md")):
        meta = front_matter(path)
        missing = [k for k in REQUIRED if not meta.get(k)]
        if missing:
            findings.append((path, "missing " + ",".join(missing)))
        elif meta["state"] != "archived":
            live += 1
            findings += [(path, p) for p in check(meta, active, today)]
    return live, findings


if __name__ == "__main__":
    roster, as_of, dirs = sys.argv[1], date.fromisoformat(sys.argv[2]), sys.argv[3:]
    live, findings = audit(dirs, roster, as_of)
    for path, problem in findings:
        print("%-36s %s" % (path, problem))
    print("live items: %d, findings: %d" % (live, len(findings)))
    if live == 0:
        print("no live items found: check the directory arguments")
        sys.exit(2)
    sys.exit(1 if findings else 0)
```

_Example status: executed on 2026-10-23 (Bash 5)._

```bash
#!/usr/bin/env bash
set -uo pipefail
item() {  # path id owner tier state last_reviewed
  mkdir -p "$(dirname "$1")"
  printf -- '---\nid: %s\nowner: %s\ntier: %s\nstate: %s\nlast_reviewed: %s\n---\n' \
    "$2" "$3" "$4" "$5" "$6" > "$1"
  printf 'Body text.\n' >> "$1"
}
item runbooks/dr/failover.md      KB-101 sre-dr      "1 # rare" validated     2026-05-02
item runbooks/payments/restore.md KB-105 sam         1          validated     2026-09-20
item procedures/it/vpn-reset.md   KB-102 li          3          validated     2025-01-15
item procedures/payroll/cutoff.md KB-103 payroll-ops 2          validated     2026-08-30
item procedures/it/legacy-ftp.md  KB-104 dev         2          archived      2023-03-01
item procedures/it/laptop-enc.md  KB-106 li          2          not_validated 2026-02-10
printf -- '---\nid: KB-107\nstate: validated\n---\nNo owner.\n' > procedures/it/printer.md
printf 'sre-dr\nli\npayroll-ops\n' > roster.txt
status=0
python3 kb_audit.py roster.txt 2026-10-23 runbooks procedures || status=$?
echo "exit=$status"
```

**Expected output** (the last line is printed by the generator; exit code 1 because findings exist):

```text
procedures/it/laptop-enc.md          tier 2 overdue by 75 days
procedures/it/printer.md             missing owner,tier,last_reviewed
runbooks/dr/failover.md              tier 1 overdue by 84 days
runbooks/payments/restore.md         owner not active: sam
live items: 5, findings: 4
exit=1
```

**Validation.** `cutoff.md` (tier 2, 54 days) and `vpn-reset.md` (tier 3) must *not* appear; archived `legacy-ftp.md` is
skipped; the `# rare` comment does not break `failover.md`'s tier. Add `sam` to `roster.txt`: the owner finding disappears. An
empty folder prints `no live items found` and exits 2. **Troubleshooting.** `bad date`: not `YYYY-MM-DD`; `unknown tier`: not
1–3; a byte-order mark before `---` hides the front matter. **Teardown.** Delete the lab directory.

#### Lab 2 (intermediate): compute knowledge-health metrics

**Objective.** Compute link rate, known share, sampled link accuracy and the Content Standard Checklist score from a ticket export
and a five-article sample. **Prerequisites.** Lab 1 environment. **Cost and risk.** None. **Steps.** Save both scripts and
`checklist.csv`, generate `tickets.csv`, run `kb_metrics.py`.

_Example status: executed on 2026-10-23 (Python 3.8.10)._

```python
"""Write tickets.csv: 40 closed tickets, 26 linked (19 existing, 7 new)."""
import csv

rows = []
for i in range(40):
    kind = "existing" if i < 19 else "new" if i < 26 else ""
    article = "KB-%d" % (100 + i % 6 if kind == "existing" else 200 + i) if kind else ""
    sample = ("no" if i == 3 else "yes") if i < 10 else ""  # 10 links sampled
    rows.append([f"T-{1000 + i}", article, kind, sample])
with open("tickets.csv", "w", newline="", encoding="utf-8") as handle:
    writer = csv.writer(handle)
    writer.writerow(["ticket_id", "article_id", "link_kind", "sample_ok"])
    writer.writerows(rows)
```

```csv
article_id,unique,complete,clear,title,links_valid,metadata
KB-201,yes,yes,yes,yes,yes,yes
KB-202,yes,no,yes,yes,yes,yes
KB-203,no,yes,yes,no,yes,yes
KB-204,yes,yes,yes,yes,yes,no
KB-205,yes,yes,yes,yes,yes,yes
```

```python
"""Knowledge health metrics from a ticket export and a checklist sample."""
import csv
import sys


def ratio(part, whole):
    return part / whole if whole else float("nan")


def ticket_metrics(path):
    rows = list(csv.DictReader(open(path, newline="", encoding="utf-8")))
    linked = [r for r in rows if r["article_id"]]
    known = [r for r in linked if r["link_kind"] == "existing"]
    sampled = [r for r in linked if r["sample_ok"] in ("yes", "no")]
    accurate = [r for r in sampled if r["sample_ok"] == "yes"]
    return {
        "closed": len(rows),
        "link_rate": ratio(len(linked), len(rows)),
        "known_share": ratio(len(known), len(linked)),
        "link_accuracy": ratio(len(accurate), len(sampled)),
        "accuracy_sample": len(sampled),
    }


def checklist_score(path):
    """Content Standard Checklist %: misses weigh double (KCS convention)."""
    rows = list(csv.DictReader(open(path, newline="", encoding="utf-8")))
    checks = [k for k in rows[0] if k != "article_id"]
    possible = len(rows) * len(checks)
    yes = sum(r[k] == "yes" for r in rows for k in checks)
    return 1 - 2 * (possible - yes) / possible


if __name__ == "__main__":
    m = ticket_metrics(sys.argv[1])
    for key in ("closed", "link_rate", "known_share", "link_accuracy"):
        value = m[key]
        print("%-14s %s" % (key, value if key == "closed" else "%.1f%%" % (100 * value)))
    print("accuracy based on %d sampled links" % m["accuracy_sample"])
    print("checklist      %.1f%%" % (100 * checklist_score(sys.argv[2])))
```

**Expected output** of `python3 make_tickets.py && python3 kb_metrics.py tickets.csv checklist.csv`:

```text
closed         40
link_rate      65.0%
known_share    73.1%
link_accuracy  90.0%
accuracy based on 10 sampled links
checklist      73.3%
```

**Validation.** By hand: 26 of 40 linked (65.0 %); 19 of 26 reuse an existing item (73.1 %); 9 of 10 sampled links accurate
(90.0 %); 30 checks with 4 misses give 1 − 2 × 4 ÷ 30 = 73.3 %, below the 90 % at which KCS suggests coaching
attention[^kcs-health]. **Troubleshooting.** `KeyError` means a header differs from the script; keep empty cells empty.

**Teardown.** Delete the files. **Caution.** Ten sampled links are far too few ([sample size](#metrics-and-kpis)).

#### Lab 3 (advanced): gate an AI index build

**Objective.** Before an index goes live, prove every chunk comes from a live item, at its current version, with an audience no
wider than the item's: the KnowledgeOps half of the [LLMOps](../llmops/) permission test. **Prerequisites.** Lab 1 environment;
in real use, exports of the knowledge base and index manifest. **Cost and risk.** None here; in production, a blocking build step.
**Steps.** Save the script and the two CSV files, then run the gate.

_Example status: executed on 2026-10-23 (Python 3.8.10)._

```python
"""Block an AI index build whose chunks disagree with the knowledge base."""
import csv
import sys

RANK = {"public": 0, "customers": 1, "internal": 2, "restricted": 3}


def load(path, key):
    with open(path, newline="", encoding="utf-8") as handle:
        return {row[key]: row for row in csv.DictReader(handle)}


def gate(kb_path, index_path):
    kb = load(kb_path, "article_id")
    problems = []
    for chunk_id, chunk in load(index_path, "chunk_id").items():
        article = kb.get(chunk["article_id"])
        if article is None:
            problems.append((chunk_id, "article no longer exists"))
            continue
        if article["state"] in ("archived", "deleted"):
            problems.append((chunk_id, "article is " + article["state"]))
        if chunk["version"] != article["version"]:
            problems.append((chunk_id, "stale: v%s indexed, v%s current"
                             % (chunk["version"], article["version"])))
        if RANK[chunk["audience"]] < RANK[article["audience"]]:
            problems.append((chunk_id, "audience widened: %s -> %s"
                             % (article["audience"], chunk["audience"])))
    return problems


if __name__ == "__main__":
    found = gate(sys.argv[1], sys.argv[2])
    for chunk_id, problem in found:
        print("%-10s %s" % (chunk_id, problem))
    print("blocking problems: %d" % len(found))
    sys.exit(1 if found else 0)
```

```csv
article_id,version,state,audience
KB-101,4,validated,internal
KB-102,2,validated,customers
KB-103,7,archived,internal
KB-104,3,validated,restricted
```

```csv
chunk_id,article_id,version,audience
c-0001,KB-101,4,internal
c-0002,KB-102,1,customers
c-0003,KB-103,7,internal
c-0004,KB-104,3,internal
c-0005,KB-099,1,public
```

**Expected output** of `python3 corpus_gate.py kb.csv index.csv; echo "exit=$?"`:

```text
c-0002     stale: v1 indexed, v2 current
c-0003     article is archived
c-0004     audience widened: restricted -> internal
c-0005     article no longer exists
blocking problems: 4
exit=1
```

**Validation.** Fix the four rows (re-index KB-102 at version 2, drop c-0003 and c-0005, label c-0004 `restricted`): the gate prints
`blocking problems: 0` and exits 0. **Troubleshooting.** `KeyError` on an audience means an unknown label: rank it, never default
it to public. **Teardown.** Delete the files. **Limits.** The gate checks labels, not query-time permissions, which LLMOps tests.


### Use cases and scenarios

Two are documented real events; three are illustrative scenarios and say so.

**A. Support team adopts KCS (illustrative scenario).** Sixty agents; two writers publish articles months late. The team moves
capture into the ticket form, starts agents as KCS Candidates with coaches, and lets reuse drive review. *Trade-off:* a capacity
dip while coaching. **Success:** link accuracy ≥ 90 %, time to publish and known share falling. **Pitfall:** an article quota
produces what KCS predicts: articles "created on the last few days of the month" with "little or no valuable
information"[^kcs-measure].

**B. Runbooks for rare events (real lessons).** GitLab's 2017 report records that replication behaviour responders needed "was not
clearly documented in our engineering runbooks", and that a backup procedure had been silently failing[^gitlab-2017]. Atlassian's
2022 review found playbooks for product-level incidents but none for an event of that scale; its actions include to "Conduct a
quarterly audit to verify readiness at all times"[^atlassian-pir]. *Method:* tier 1, because demand never reviews knowledge nobody
uses until the worst day. *Trade-off:* review cost for items rarely read. **Success:** rehearsal findings closed. **Pitfall:**
reviewing on paper only; a rehearsal finds the step that no longer works.

**C. Engineering docs move to source control (real).** Google moved important documentation from its GooWiki into source control,
where "Documents began to have their own owners, canonical locations within the source tree, and processes for identifying bugs
and fixing them"; documentation "began to dramatically improve", and freshness metadata sends reminders when a document "hasn't
been touched in, for example, three months"[^swe-docs]. **Pitfall:** engineers feared the higher bar to edit would hurt quality;
the book reports it did not[^swe-docs].

**D. AI assistant over internal knowledge (illustrative scenario).** The assistant shows only what each user can open[^copilot],
so the risk lies in the permissions: a restricted salary procedure saved in an open space is one prompt away for everyone. The
[judgement call](#a-judgement-call-index-everything-or-start-from-an-allowlist) works through the method. *Trade-off:* coverage
starts small. **Success:** zero restricted answers in quarterly red-team prompts; the "no answer" rate falls as domains join.
**Pitfall:** adding domains without the gate because the first month went well.

**E. Chat answers become runbooks (illustrative scenario).** A platform team answers the same questions in its help channel every
week. Each Friday the on-call engineer lists questions answered twice; the team lead assigns each to an owner, who writes or fixes
an item in the asker's words, and the channel answers with links from then on. *Trade-off:* writing time. **Success:** repeat
questions per week fall. **Pitfall:** pasting chat threads into a wiki unedited, with no owner, no tier and one conversation's
context. Chat mechanics are on [ChatOps](../chatops/).

## Measure, secure and pay

### Metrics and KPIs

KCS separates *activities* (leading indicators, never goals) from *outcomes* (lagging, goal-worthy) and triangulates them with
the Content Standard Checklist; an indicator that is "Easy to measure and easy to manipulate or game" is probably an
activity[^kcs-measure].

| KPI | Definition and formula | Kind | Pitfall |
|---|---|---|---|
| Link rate | Closed tickets with ≥ 1 linked item ÷ closed tickets | Activity (trend only) | Rewards linking anything |
| Link accuracy | Sampled links whose item resolves the issue ÷ sampled links | Outcome | Small samples are imprecise (below) |
| Known share (assisted) | Links to existing items ÷ all links | Outcome signal | High = known issues miss self-service |
| Content Standard Checklist % | 1 − 2 × (possible − passed) ÷ possible[^kcs-health] | Coaching signal | Not an accuracy review |
| Tier-1 freshness | Tier-1 items reviewed within 90 days ÷ tier-1 items | Outcome | Rubber stamps; pair with rehearsals |
| Ownerless ratio | Live items whose owner is not active ÷ live items | Health | Group owners hide departed members |
| Failed-search rate | Searches with no click or no result ÷ searches | Findability | Bots and typos inflate it |
| Time to publish | Minutes from "relief given" to the item "published", visible through self-service[^kcs-metrics] | Flow | Slow review queues |

**Targets with evidence.** For credible input to product teams KCS wants "link rates that exceed 60% and link accuracy that
exceeds 90%"[^kcs-health]; for assisted support its ideal is "85% new"[^kcs-metrics]. Both come from support experience.

**Sample size (Atlas arithmetic).** A sampled accuracy *p* from *n* links has a 95 % margin of about 1.96 × √(*p*(1 − *p*) ÷ *n*):
at *p* = 0.9, ±8 points for 50 samples and ±5 for about 140. Fifty links cannot tell 85 % from 90 %.

**Worked example (illustrative).** One month: 2,000 closed tickets, 1,240 linked: link rate **62 %**. A coach samples 80 links;
68 resolve the issue: accuracy **85 %**, ±8 points (77–93 %), so the 90 % bar is not shown; fix search and coaching and sample
more before any product report. 930 links reuse an existing item: known share **75 %**, so publish those items to customers
(with [SupportOps](../supportops/)) rather than write more. 31 of 40 tier-1 runbooks were reviewed within 90 days: freshness
**77.5 %**, a gap to escalate.

**Data limitations.** Accuracy needs human sampling; self-service success needs click-path or survey methods[^kcs-metrics].

### Quality, security, privacy and compliance

| Risk | Signal | Mitigation | Owner |
|---|---|---|---|
| Wrong item followed in production | Postmortem cites a runbook step | Tier 1, rehearsal, compliance-based governance | Item owner |
| Restricted item reaches a wider audience | Label audit; Lab 3 gate | Audience metadata; gate on every build | KnowledgeOps lead, security |
| Personal data in articles | Names, customer screenshots | Content standard bans it; redact at capture | Knowledge worker, privacy |
| Erasure not applied to indexes | Deleted item still retrievable | Deletion propagates to derived views; verify | Privacy, platform |
| Poisoned or unvetted source in corpus | New repository appears in index | Corpus allowlist; "trusted and verified sources"[^owasp-llm08] | Security |

**Evidence retention.** To show what you told someone, keep the version delivered: KCS suggests a snapshot in the
incident or article version control[^kcs-state]. Legal duties differ by jurisdiction; [PrivacyOps](../privacyops/) and
[ComplianceOps](../complianceops/) own them.

### Cost, capacity and sustainability

The costs are mostly people's time:

- **Capture and coaching** cost capacity in each adoption wave[^kcs-roi].
- **Review.** Calendar review scales with item count, reuse review with demand. Illustrative, at 10 minutes per review: 3,000
  items once a year cost 500 hours; 50 tier-1 items four times and 100 tier-2 items twice a year cost about 67 hours, plus
  rehearsals.
- **Re-indexing.** An embedding "must be recomputed whenever the document changes or whenever the embedding model is upgraded", a
  significant recurring cost at scale[^finops-ai-tools]; see [FinOps for AI](../finops-for-ai/).
- **Benefits** need your own baseline before you claim them.


### Assurance of the operating model

Beyond the KPIs:

- **Process Alignment Review**: "how well and how often knowledge workers are contributing to the Solve Loop"[^kcs-evolve].
- **Stagnation.** KCS warns that "the system slowly dies" when articles stop flowing to self-service and participation
  drops[^kcs-state]; watch the monthly snapshot of states and time to publish.
- **Rehearsal findings** for tier-1 items, tracked like incident actions.
- **Index reconciliation** results (Lab 3) on every build, plus a quarterly red-team of the assistant with restricted questions.
- **Owner hygiene**: ownerless ratio after every reorganisation.

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Three items answer one question differently | Capture without searching first | Duplicate cluster in search | Merge to one canonical item | "Search early"; uniqueness check |
| Agents stopped linking | Linking is slow, or the data is unused | Link rate trend by team | One-click linking | Report Evolve Loop findings back monthly |
| Article counts up, quality down | Goals on activities | Checklist scores of high producers | Remove activity goals; coach | Outcome goals only[^kcs-measure] |
| Runbook failed during an incident | Tier-1 item never rehearsed | Postmortem; review history | Fix, rehearse, add owner | Tier policy; game days |
| Search finds nothing for common words | Items written in insider terms | Failed-search report | Add asker's phrases and synonyms | Capture the requestor's words |
| Assistant cites a retired procedure | Archive missed the index | Chunk id → item → state | Remove chunks; rebuild | Gate every build ([runbook](#runbook-the-assistant-quotes-a-retired-procedure)) |

### Runbook: the assistant quotes a retired procedure

**Situation (illustrative).** The internal assistant answers "how do I get a production database credential?" with the old
ticket-based process and cites a page the platform team archived last month. Two people have already sent requests to an
unmonitored queue.

::: figure Runbook for a stale or over-shared answer from an AI assistant
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 16, "rankSpacing": 28, "padding": 8}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  A["1 Report: answer cites item KB-412"]:::risk
  B["2 Trace chunk id to item id, version, state, audience"]:::core
  C{{"3 Is the source archived, outdated or wider than its audience?"}}:::decision
  D["4 Contain: delete the chunks; block the item id at query time"]:::risk
  E["5 Correct: tell people who acted; fix or point to the current item"]:::core
  F["6 Find the gap: why did archiving not reach the index?"]:::core
  G["7 Prevent: gate every build; add a test case"]:::core
  H["Content is current: route to LLMOps as a retrieval fault"]:::core
  A --> B --> C
  C -->|"yes"| D --> E --> F --> G
  C -->|"no"| H
```
Text equivalent: An answer cited KB-412. Responders trace the chunk to the item's id, version, state and audience. If the source
is archived, outdated or wider than its audience, they contain (delete chunks, block the id), correct (tell those who acted),
find the gap and prevent a repeat (gate every build, add a test). If the content is current, LLMOps treats it as a retrieval fault.
:::

What the figure leaves out:

1. **Trace**: chunk → KB-412, version 6 indexed, archived since 2026-09-28.
2. **Contain** within the hour; search the index for copies under other ids (a team wiki had pasted the text).
3. **Correct**: tell the two requesters the current route, check the queue, add a "retired, see KB-530" banner.
4. **Root cause**: the index sync handled edits but not state changes. A *restricted* item makes this a data exposure for
   security and [PrivacyOps](../privacyops/).
5. **Prevent and verify**: Lab 3 gate as a blocking step and an LLMOps regression case; re-ask and expect KB-530 cited.

### Anti-patterns and myths

- **"Write everything down."** Unowned documents become obsolete[^swe-docs]; capture what is demanded.
- **Article quotas.** Goals on activities "corrupt the knowledge base"[^kcs-measure].
- **Annual review of everything.** Wastes effort on unused items and misses the runbook that changed last month.
- **Shrinking the base to fix search.** KCS calls archiving old articles treating "the symptoms of findability, not the
  cause"[^kcs-archive]. (AI corpora differ; see the [judgement call](#a-judgement-call-index-everything-or-start-from-an-allowlist).)
- **The hero expert.** KCS: "The new hero in the organization is the person who creates value through their contribution to the
  knowledge base"[^kcs-health].
- **"The AI will organise it."** An assistant inherits your permissions and your stale pages[^copilot][^ms-genaiops].

## Deciding and adopting

### When to use and when not to use

**Use it** when the same questions recur, when people wait for a few experts, when onboarding is slow, when incidents last longer
because procedures are missing, or before connecting an AI assistant to internal content.

**Do not invest in a programme** when the work is mostly novel, when a handful of people sit together, or when the knowledge
changes faster than anyone can write it (then pair or swarm). KCS says the key value factor is "the degree to which knowledge or
experience plays a role in responding to user's or customer's requests for assistance"[^kcs-roi]. **Hidden costs:** coaching,
owners' review time, tool integration, and the politics of removing activity quotas. **Alternatives:** a well-owned FAQ, recorded
walkthroughs, or pairing.

### Decision framework

The key decision is which review engine each class of knowledge gets; the tree is this Atlas's proposal.

::: figure Choosing a review engine for a class of knowledge items
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 140, "nodeSpacing": 16, "rankSpacing": 28, "padding": 8}}}%%
flowchart TB
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  Q1{{"Could following a wrong copy cause serious harm?"}}:::decision
  Q2{{"Is it used at least monthly?"}}:::decision
  Q3{{"Does it change on a known schedule or with known systems?"}}:::decision
  T1["Tier 1: 90-day owner review plus rehearsal; compliance-based edits"]:::core
  T2["Tier 2: review on every dependent change, 180-day backstop"]:::core
  T3["Tier 3: reuse is review; archive on obsolescence"]:::neutral
  Q1 -->|"yes"| Q2
  Q1 -->|"no"| Q3
  Q2 -->|"no"| T1
  Q2 -->|"yes"| T2
  Q3 -->|"yes"| T2
  Q3 -->|"no"| T3
```
Text equivalent: Could following a wrong copy cause serious harm? If so and the item is used less than monthly, it is tier 1:
90-day owner review, rehearsal, designated editors. If harmful but used at least monthly, or harmless but changing on a known
schedule or with known systems, it is tier 2: review on every dependent change with a 180-day backstop. Otherwise it is tier 3:
reviewed by reuse, archived when obsolete.
:::

For tool choice, weight: ticket or incident linking, export with metadata and links, and an audience and state model (high);
verification reminders and failed-search analytics (medium); AI features (low until the basics work).

### Maturity model

**This Atlas's model**, not an official one. ScreenSteps publishes three stages (Tribal, Document, Guide)[^ss-maturity]; KCS
describes adoption phases (Plan and Design, Adopt in Waves, Build Proficiency, Optimize and Innovate)[^kcs-roi].

| Level | Observable behaviour | Exit criteria |
|---|---|---|
| 0 Tribal | Answers live in heads and chat | A repository exists and people know where |
| 1 Documented | Pages exist; nobody owns them; duplicates | Metadata contract; owner on ≥ 90 % of live items |
| 2 Owned | Owners, states, audiences; tier policy | Tier-1 freshness ≥ 90 %; ownerless ratio < 5 % |
| 3 Integrated | Capture and linking in the workflow; monthly scorecard | Link accuracy ≥ 90 % sampled; time to publish tracked |
| 4 Learning | Evolve Loop drives product and process fixes; corpus gated for AI | Root-cause fixes traced to link data; zero gate failures in production |

### Adoption roadmap: 30/60/90 days

| Window | Actions | Milestone |
|---|---|---|
| Days 1–30 | Pick one domain (a support queue or an on-call rota); write the metadata contract; inventory items and owners; run Lab 1; tier the top 50 items | Baseline: ownerless ratio, tier-1 freshness, link rate |
| Days 31–60 | Train search, link, flag or fix; appoint coaches; one-click linking; checklist sampling; rehearse two tier-1 runbooks | Link accuracy measured, with its margin |
| Days 61–90 | First Evolve Loop review; archive duplicates; publish validated items; gate any AI index (Lab 3) | Leadership reviews the scorecard and decides on expansion |

## Toolkit

### Checklists

**Quick start**

- [ ] One domain, a named KnowledgeOps lead and a sponsor
- [ ] Metadata contract published; tiers defined; audit (Lab 1) running weekly
- [ ] Linking available in one click from tickets or incidents

**Before connecting an AI assistant**

- [ ] Corpus allowlist by domain, state and audience; nothing ownerless
- [ ] Index chunks carry item id, version and audience; Lab 3 gate blocks the build
- [ ] Archive and deletion reach the index within an agreed time; erasure route agreed with privacy
- [ ] Red-team prompts for restricted content run before launch and quarterly

**Monthly review**

- [ ] Scorecard reviewed ([metrics](#metrics-and-kpis)), with sample margins
- [ ] Ten worst failed searches turned into items or synonyms
- [ ] Duplicates merged; flags older than 14 days resolved; no tier-1 domain with a single capable person

### Templates

**Item template** (KCS-style structure: issue in the asker's words, environment, resolution, cause[^kcs-aqi]):

```text
Title:        <main issue> on <main environment>
Issue:        <the asker's words; exact error text in quotes>
Environment:  <product, version, platform; one per line>
Resolution:   1. <present-tense step>  2. <step>
Cause:        <optional; one cause per item>
Metadata:     id | owner | tier | state | audience | last_reviewed | version
```

**Tier-1 review form**

```text
Item / version:      KB-____ v__        Reviewer (owner): ________
Systems it touches:  ________  Changed since last review?  yes / no
Walked through on:   paper / staging / game day (date ____)
Steps that failed or were unclear: ________
Outcome:  confirmed | corrected (new version __) | archived
Next review due:     ____-__-__   Next rehearsal: ____-__-__
```

**Retirement request**

```text
Item: KB-____   Requested by: ____   Reason: obsolete | duplicate | wrong
Replacement item: KB-____ (or none)   Linked records exist? yes / no
Action: archive (linked) | delete (unlinked and wrong)
Remove from: search | help centre | AI index (verify chunk count = 0)
```

### Deep comparisons

| Approach | Best for | Review model | Weakness |
|---|---|---|---|
| KCS in a knowledge base | Support and service desks | Reuse is review; coaching | Needs linking and culture change |
| Docs as code | Runbooks, engineering procedures | Pull requests; owners; freshness dates | Barrier for non-engineers |
| Editorial ([ContentOps](../contentops/)) | Product docs, public guides | Planned editorial review | Slow for fast-changing answers |
| Open wiki | Early-stage teams | None by default | Ownerless decay[^swe-docs] |

Two maintenance philosophies disagree. Google advises "Default to delete or leave behind if migrating"[^google-docguide]; KCS
says "Archiving an article is better than deleting it" when tickets link to it[^kcs-state]. Deletion suits unlinked engineering
pages; archiving suits items in a service record.


### FAQ

**Is KnowledgeOps a job title?** Rarely. ScreenSteps names a "Knowledge Ops Manager"[^ss-blog]; most say knowledge manager or KCS
programme lead.

**Is KCS only for customer support?** No. Members are "adopting KCS across their entire company, including HR, legal, marketing,
sales, product management and development organizations"[^kcs-new], though the evidence comes mostly from support.

**Do we need ISO 30401 certification?** Only if a customer or regulator asks for it. You can adopt the management-system
discipline without certifying, and a revised edition is close (as of October 2026)[^iso-proj].

**Our most experienced engineer leaves in a month. What first?** Reassign everything they own this week, then walk-through
interviews and pairing for their tier-1 procedures ([tacit knowledge](#tacit-knowledge-capture-and-retention)).

**Can AI write our knowledge base?** It can draft from tickets and incidents; drafts stay Not Validated until a proficient person
confirms them. Volume without validation is an activity goal in disguise.

## Going further

### Advanced topics and emerging direction

- **Knowledge-Centered Success** (new edition): certifications roll out in late 2026 and 2027[^kcs-cert].
- **Knowledge graphs** (established technique, uneven practice): SKOS-style vocabularies link items, systems and terms[^skos];
  most teams need synonyms first.
- **Agentic assistants that edit knowledge** (emerging): "Empower to Improve" in the new KCS guide includes "permissioned people and
  systems"[^kcs-solve]; an editing agent needs the same proficiency rules as a person.
- **Answer-level freshness** (speculative): a corrected item invalidates past answers that cited it. Little published practice
  exists.

### Learning path

| Stage | Do this |
|---|---|
| Prerequisites | None; read the [glossary](#glossary-and-mental-model) |
| 1 day | Read the KCS Solve Loop pages[^kcs-solve]; run Lab 1 |
| 1 week | Tier 50 real items; draft a metadata contract; run Lab 2 on a ticket export |
| 30 days | Run the 30-day roadmap in one domain; run the expert-leaving playbook once |
| Advanced | KCS certification; Lab 3 with your LLMOps team; ISO 30401 |
| Portfolio | A before-and-after scorecard for one domain, with the decisions it drove |

## Wrap-up

### Executive recap and cheat sheet

- **Decide:** which domains first; tier policy; who owns what; goals on outcomes only.
- **Practise:** search early, link, flag or fix, capture in the asker's words, rehearse tier-1 runbooks, hand over before people leave.
- **Measure:** the [scorecard](#metrics-and-kpis), with sample margins.
- **Tool classes:** knowledge base with verification; docs as code with CODEOWNERS; link and metadata checks; gated AI index.
- **Watch out:** article quotas, annual review of everything, experts leaving unannounced, archived items in AI indexes.
- **Next action:** run Lab 1 against your real repository this week.

### A judgement call: index everything, or start from an allowlist?

**Situation (illustrative).** A 3,000-person company switches on an internal assistant in six weeks. Its wiki holds about 40,000
pages; a third have no active owner, and nobody knows how many are restricted but openly shared. Option A (the vendor's default):
index everything users can open; clean up as complaints arrive. Option B: index an allowlist of owned, labelled domains (about
6,000 items) and grow it monthly.

**Assumptions.** The assistant trims results to each user's permissions[^copilot]; wiki permissions are loose; leadership will
judge the launch by month-one coverage.

**Reasoning.** (1) *Worst failure.* A: an over-shared restricted page is one question away for everyone, and stale pages answer
fluently. B: "I don't know" outside the allowlist. (2) *Does demand-driven cleanup rescue A?* "Reuse is review" works because a
trained responder judges each article in context[^kcs-reuse-review]; an assistant user sees a fluent paragraph without age or
state, so errors surface only after someone acts. (3) *Cost of B.* Lower launch coverage, owner work on 6,000 items. (4) *What
would change the answer.* Recently audited permissions and mostly owned content.

**Decision: B,** with the wiki's ordinary search, which shows dates and authors, left for everything else. The attractive choice,
A, buys coverage with risks invisible until the first leak. **Uncertainty:** how fast the allowlist can grow; let weekly "no
answer" questions choose the next domains.

### Learning objectives and mastery check

After this page you can **explain** the label and its boundaries, **design** a metadata contract and tier policy, **operate** the
Solve and Evolve loops, **measure** knowledge health without quotas, **retain** an expert's knowledge, and **evaluate** a corpus
before an AI launch.


::: answer 1. A director proposes "ten articles per agent per month". What do you say, and what do you propose instead?
KCS predicts month-end articles with little value[^kcs-measure]. Track creation as a trend only; set goals on link accuracy, time
to publish and self-service success.
:::

::: answer 2. Your disaster-recovery runbook was viewed twice this year. Is "reuse is review" enough?
No. Reuse never triggers and errors are costly: tier 1, with 90-day and change-triggered owner review plus rehearsal.
:::

::: answer 3. Link rate is 70 %, sampled accuracy 72 % on 60 links. Can product managers trust the top-ten issues list?
Not yet. Even with a margin of about ±11 points, accuracy is below the 90 % KCS asks for[^kcs-health]; fix search and coaching.
:::

::: answer 4. An item was archived last week, but the assistant still quotes it. Where do you look first?
The index build: archiving changed the record, not the derived view. Trace the chunk, delete it, add the Lab 3 gate
([runbook](#runbook-the-assistant-quotes-a-retired-procedure)).
:::

::: answer 5. Should you delete or archive a wrong troubleshooting article linked from 300 tickets?
Archive it and point to the replacement: deleting breaks the links from records[^kcs-state]. Remove it from every index.
:::

::: answer 6. Known share in assisted support is 75 %. Good or bad?
A warning sign: KCS's ideal is about 85 % new[^kcs-metrics]; known issues should be solved in self-service. Publish validated
items with SupportOps.
:::

::: answer 7. Your only payments-restore expert resigns. The runbook exists. Is that enough?
No. Reassign it, have the successor rewrite it from a walk-through interview, and rehearse it before the last day
([tacit knowledge](#tacit-knowledge-capture-and-retention)).
:::

### Conclusion

"KnowledgeOps" is a vendors' word for an old problem. It adds no new method: the method is knowledge management, codified
for service work by KCS. The operations framing helps: run knowledge as an operated asset, with owners, states, service levels
and incident handling. The hard part is choosing which knowledge needs calendar review, keeping owners real as people leave, and
making every copy, especially the one an AI reads, carry an item's state and audience. Product facts are dated October 2026;
re-check them, and the KCS facts once the 2027 certifications ship.


## Sources and further reading

Ledger: `research/knowledgeops-ledger.md`. KCS library pages show no dates; "v6" marks the KCS v6 Practices Guide, "KCS 2027" the
Knowledge-Centered Success guide published in 2026.


[^ss-blog]: [What is Knowledge Operations in Business?](https://blog.screensteps.com/what-knowledge-operations-in-business) — ScreenSteps (Rebecca Lane), 2025-02-21. Checked 2026-10-23.
[^ss-devore]: [ScreenSteps vs. traditional knowledge base](https://blog.screensteps.com/screensteps-vs-traditional-knowledge-base) — ScreenSteps (Greg DeVore), 2023-11-24. Checked 2026-10-23.
[^ss-help]: [What is Knowledge Ops?](https://help2.screensteps.com/a/1974097-what-is-knowledge-ops) — ScreenSteps Help, updated 2025-09-29. Checked 2026-10-23.
[^ss-maturity]: [The Knowledge Ops Maturity Model](https://blog.screensteps.com/knowledge-ops-maturity-model-how-effective-knowledge-operations) — ScreenSteps (Greg DeVore), 2025-02-13. Checked 2026-10-23.
[^kmworld-2021]: [Augmented Intelligence for the Enterprise](https://aboveandbeyondkm.com/2021/11/16/augmented-intelligence-for-the-enterprise/) — V. Mary Abraham, notes from KMWorld Connect 2021, 2021-11-16. Checked 2026-10-23.
[^knowmax]: [KnowledgeOps: Knowledge Management Stopped Being a Content Job](https://knowmax.ai/blog/knowledgeops/) — Knowmax (Pratik Salia), 2026-08-24, updated 2026-09-30. Checked 2026-10-23.
[^deeml]: [What Is Knowledge Operations (KnowledgeOps)?](https://deeml.com/technology/knowledge-operations) — Deeml Inc., undated. Checked 2026-10-23.
[^skill]: [knowledge ops skill](https://www.skills.sh/affaan-m/ecc/knowledge-ops) — skills.sh listing of the affaan-m/ecc repository. Checked 2026-10-23.
[^kcs-new]: [Knowledge-Centered Success Practices Guide](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-whatsnew]: [What's New in Knowledge-Centered Success](https://library.serviceinnovation.org/KCS/KCS_Resources/New_in_Knowledge-Centered_Success) — Consortium for Service Innovation. Checked 2026-10-23.
[^kcs-cert]: [KCS Certification & Training](https://library.serviceinnovation.org/KCS/KCS_Certification_and_Training) and [Knowledge-Centered Success Training and Certification](https://library.serviceinnovation.org/KCS/KCS_Certification_and_Training/Knowledge-Centered_Success_Training_and_Certification) — Consortium for Service Innovation. Checked 2026-10-23.
[^kcs-solve]: [The Solve Loop](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/201-Solve_Loop) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-evolve]: [The Evolve Loop](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/301-Evolve_Loop) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-article]: [Output: the KCS Article](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/102-Output_the_KCS_Article) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-link]: [Technique 1.3: Track Reuse](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/201-Solve_Loop/Practice_1_Reuse/Technique_1.3) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-v6-link]: [Technique 3.3: Linking](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/030/030/030) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-measure]: [Technique 7.1: Measure the Right Things](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/301-Evolve_Loop/Practice_7_Performance_Insight/Technique_7.1) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-roi]: [Technique 7.3: KCS Program Benefits and ROI](https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/301-Evolve_Loop/Practice_7_Performance_Insight/Technique_7.3) — Consortium for Service Innovation (KCS 2027). Checked 2026-10-23.
[^kcs-why]: [Why KCS?](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/020/010) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-capture]: [Technique 1.1: Capture Knowledge in the Moment](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/030/010/010) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-reuse-review]: [Technique 4.1: Reuse is Review](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/030/040/020) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-license]: [Technique 4.3: License to Modify](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/030/040/040) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-state]: [Technique 5.2: KCS Article State](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/040/010/030) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-archive]: [Technique 5.5: Archiving Old Articles](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/040/010/044) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-health]: [Technique 5.10: Content Health Indicators](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/040/010/065) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-roles]: [Technique 7.1: KCS Roles and the Licensing Model](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/040/030/020) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-metrics]: [Appendix C: Metrics Matrix](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/070) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-aqi]: [Appendix E: Article Quality Quick Reference Guide](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/090) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^kcs-itil]: [Appendix F: KCS and ITIL](https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/093) — Consortium for Service Innovation (v6). Checked 2026-10-23.
[^iso30401]: [ISO/TC 260 ongoing projects: ISO/DIS 30401](https://committee.iso.org/sites/tc260/home/projects/ongoing/ongoing-5.html) — ISO TC 260 (standard ISO 30401:2018). Checked 2026-10-23.
[^iso-proj]: [ISO/DIS 30401 Knowledge management systems — Requirements](https://iss.rs/en/project/show/iso:proj:89436) — Institute for Standardization of Serbia, mirror of ISO project 89436 (stage 40.60, 2026-09-18). Checked 2026-10-23.
[^tacit]: [Tacit knowledge](https://en.wikipedia.org/wiki/Tacit_knowledge) — Wikipedia (citing Polanyi 1966; Nonaka and Takeuchi 1995). Checked 2026-10-23.
[^swe-docs]: [Software Engineering at Google, chapter 10: Documentation](https://abseil.io/resources/swe-book/html/ch10.html) — Tom Manshreck, ed. Riona MacNamara; O'Reilly, 2020. Checked 2026-10-23.
[^swe-share]: [Software Engineering at Google, chapter 3: Knowledge Sharing](https://abseil.io/resources/swe-book/html/ch03.html) — Nina Chen and Mark Barolak, ed. Riona MacNamara; O'Reilly, 2020. Checked 2026-10-23.
[^pairing]: [On Pair Programming](https://martinfowler.com/articles/on-pair-programming.html) — Birgitta Böckeler and Nina Siessegger, martinfowler.com, 2020-01-15. Checked 2026-10-23.
[^cop]: [Introduction to communities of practice](https://www.wenger-trayner.com/introduction-to-communities-of-practice/) — Etienne and Beverly Wenger-Trayner, 2015. Checked 2026-10-23.
[^google-docguide]: [Documentation best practices](https://google.github.io/styleguide/docguide/best_practices.html) — Google style guides. Checked 2026-10-23.
[^wtd]: [Docs as Code](https://www.writethedocs.org/guide/docs-as-code/) — Write the Docs. Checked 2026-10-23.
[^diataxis]: [Diátaxis](https://diataxis.fr/) and [Start here](https://diataxis.fr/start-here/) — Daniele Procida. Checked 2026-10-23.
[^skos]: [SKOS Simple Knowledge Organization System Reference](https://www.w3.org/TR/skos-reference/) — W3C Recommendation, 2009-08-18. Checked 2026-10-23.
[^so-2024]: [2024 Developer Survey: Professional Developers](https://survey.stackoverflow.co/2024/professional-developers) — Stack Overflow, 2024. Checked 2026-10-23.
[^sre-intro]: [Site Reliability Engineering, Introduction](https://sre.google/sre-book/introduction/) — Google (Beyer et al., O'Reilly), 2016. Checked 2026-10-23.
[^gitlab-2017]: [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — GitLab, 2017-02-10. Checked 2026-10-23.
[^atlassian-pir]: [Post-Incident Review on the Atlassian April 2022 outage](https://www.atlassian.com/blog/how-we-build/post-incident-review-april-2022-outage) — Atlassian, 2022-04-29. Checked 2026-10-23.
[^codeowners]: [About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) — GitHub Docs. Checked 2026-10-23.
[^gh-protected]: [About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) — GitHub Docs. Checked 2026-10-23.
[^gha-expr]: [Expressions: status check functions](https://docs.github.com/en/actions/reference/workflows-and-actions/expressions) — GitHub Docs. Checked 2026-10-23.
[^gh-envs]: [Deployments and environments](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments) — GitHub Docs. Checked 2026-10-23.
[^gh-envs-manage]: [Managing environments for deployment](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) — GitHub Docs. Checked 2026-10-23.
[^gh-logs]: [Using workflow run logs](https://docs.github.com/en/actions/how-tos/monitor-workflows/use-workflow-run-logs) — GitHub Docs. Checked 2026-10-23.
[^gha-schedule]: [Events that trigger workflows: schedule](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows) — GitHub Docs. Checked 2026-10-23.
[^lychee]: [lychee](https://github.com/lycheeverse/lychee) — lycheeverse. Checked 2026-10-23.
[^lychee-action]: [lychee-action v2.9.0 action.yml](https://github.com/lycheeverse/lychee-action/blob/v2.9.0/action.yml) — lycheeverse, released 2026-07-09. Checked 2026-10-23.
[^vale]: [Vale documentation](https://docs.vale.sh/) — Vale. Checked 2026-10-23.
[^techdocs]: [TechDocs](https://backstage.io/docs/features/techdocs/) — Backstage (CNCF). Checked 2026-10-23.
[^zendesk-verify]: [About article verification and how it works](https://support.zendesk.com/hc/en-us/articles/5588297664666-About-article-verification-and-how-it-works) — Zendesk. Checked 2026-10-23.
[^guru-verify]: [Verification](https://www.getguru.com/features/verification) — Guru. Checked 2026-10-23.
[^copilot]: [Data, Privacy, and Security for Microsoft Copilot](https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy) — Microsoft Learn, 2026-07-09. Checked 2026-10-23.
[^owasp-llm08]: [LLM08:2025 Vector and Embedding Weaknesses](https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/) — OWASP GenAI Security Project, 2025. Checked 2026-10-23.
[^ms-genaiops]: [Generative AI Operations for Organizations with MLOps Investments](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/genaiops-for-mlops) — Microsoft Learn, 2025-09-16. Checked 2026-10-23.
[^finops-ai-tools]: [FinOps for AI: tools and services considerations](https://www.finops.org/wg/finops-for-ai-tools-services-considerations/) — FinOps Foundation. Checked 2026-10-23.
[^anthropic-halluc]: [Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations) — Anthropic. Checked 2026-10-23.

**Changelog.** 2026-10-23: first complete draft (Blueprint v2, 13 H2 parts, six diagrams, three executed labs); term status
vendor-specific confirmed; KCS facts updated for the April 2026 Knowledge-Centered Success edition. 2026-10-23 (r1 revision): Lab 1 audit
recurses, strips comments, fails on zero items; two-job workflow, roster fetched at run time; tacit-knowledge section; 2021
"knowledge ops" use, ISO status; encodable tiers; KCS departure stated; shortened. 2026-10-23 (final-QA revision): empty footnote fixed; environment administrator-bypass
precondition; KCS "proficient" wording; trimmed.
2026-10-23, post-score polish: UTC "by default"; paid-plan note covers environment secrets; three-column methods table.