# 8.6 KSoR: what is officially true (/managing-ai-workers/context-memory-knowledge-and-state/ksor) --- type: Document title: "8.6 KSoR: what is officially true" description: "How a company keeps the rules it has approved: each rule written once, an approval that is recorded, and three statuses a rule can have." status: stable order: 208.6 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-07T18:30:04Z chapter: "08" part: II expert_status: required concepts: [ "8.6" ] last_verified: 2026-10-07 sources: - id: ksor title: "KSoR, the Knowledge System of Record (Panaversity, GitHub, verified 2026-10-07)" resource: https://github.com/panaversity/ksor generated: at: 2026-10-07T18:30:04Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87 dirty: true ksor_version: 0.0.60 --- **In everyday life.** Think of a school's official handbook. Teachers may have notes, but when parents argue about a rule, the handbook page that the head of the school approved settles it. **What you will learn.** How a company keeps the rules it has approved: each rule written once, with an owner, a recorded approval and a review date. You practice it in step 2 of the build step. **Why it matters.** "Approved" only helps when anyone can check it: who approved which text, when, and until when. KSoR, the Knowledge System of Record, is how a company keeps what it has approved as true, such as its policy. Its design is built on three lines: **one authoritative record**, **one governance boundary**, **many open projections**.[^ksor] **One authoritative record.** Authoritative means official: the record is the one place whose word is final. Each rule is written once, in a **concept**: a short Markdown file, plain text with a few marks for headings and lists. Its header, at the top, says who owns it and what its status is. At Brightline, the book's example company, "invoice approval threshold" is one concept: it says which invoices need approval. It is not a paragraph in three different files. **One governance boundary.** Governance means the rules for who may approve and change knowledge. In KSoR's own format, a concept's status has exactly three values:[^ksor] - Knowledge enters the record as a **draft**. - It becomes **stable**, the status that may be served, only when an authorized person approves it, and that approval is recorded. Served means given out to people and AI tools. - When a rule is replaced, the old concept becomes **deprecated** and points to its successor, the new concept. Approval is an event, not a status: it happens on a date, and the record keeps it. An edited concept does not have to be replaced: it can be approved again instead. Taking knowledge out of use is a separate, recorded step called a takedown, which Chapter 10 covers. Figure 8.7 shows a concept's header from Brightline's AP policy. AP means accounts payable, the bills a company owes. The header names: - the owner, the person responsible for the rule - the approval: who approved it, and when - the effective date, the day a rule starts to apply - the review date (stale_after in the header), the day the owner must check the rule again - the sources the rule comes from - the audience, who may read it In the figure, the rule has applied since September 1, 2026, when Dave, the controller, approved AP policy version 3, its source. The concept that holds the rule was approved later, on November 4, 2026. The dates are written year-month-day. ![The title reads "A KSoR concept and its lifecycle." The line below it reads "One topic, one governed record. Approval makes a draft eligible for use." On the left, the file knowledge/invoice-approval-threshold.md, with selected fields from its header: type Policy, title Invoice approval threshold, status stable, a source that is AP policy version 3, a stale_after date of 2027-03-31, audience ap-team, owner Dave Kowalski, an approval by Dave Kowalski on 2026-11-04, and an effective_from date of 2026-09-01. Status, owner and approval are highlighted. Below the header, the policy text: "Invoices over $5,000.00 need the controller's approval before payment." On the right, "Three status values." Draft: authoring and review only, not served as approved policy. An arrow labeled "Recorded approval by an authorized person" leads to stable: eligible for governed serving, and it must be in force, within its review date and allowed for the audience. An arrow labeled "Replaced by a successor" leads to deprecated: excluded from operational policy retrieval, and kept with a link to its successor. A note reads "Changes to a stable concept require re-approval." A red banner at the foot reads "Approval is an event, not a status value. Takedown is a separate recorded withdrawal (Chapter 10)."](img/ksor-concept.png) *Figure 8.7. A KSoR concept and its lifecycle. Only stable concepts in force, past their effective date and before their review date, are served to machines.* **Many open projections.** A projection is one way of publishing the record. KSoR publishes the same record in four ways:[^ksor] - a website for people - files for AI discovery, which tell AI tools what the record holds - a server that AI agents ask for knowledge over MCP. MCP (Model Context Protocol) is a standard way to connect AI apps to other systems. - exchange bundles, packages of the record for other systems No knowledge leaves the record by one of those four ways without passing the governance decision. That decision checks that it is stable, in force, before its review date, and allowed for that reader. KSoR never serves a draft to a machine, such as an AI tool. Copying concepts by hand into an AI vendor's project, a workspace in its product, is not one of the four. KSoR also has two principles about answers: *citation before confidence*, and *abstention is a feature*.[^ksor] Citation means naming the source. An answer about policy should name the concept it is based on. Abstention means declining to answer. When the record does not cover a question, the right answer is "the record does not say." At Brightline, an AI Worker's project held the approved policy beside old notes nobody approved. Nothing marked which files were official, so nothing in the project could say "the record does not say." In Part II, this part of the book, you copy concepts into projects by hand. That has three limits: 1. Your copies in an AI vendor's project are not a governed projection, so the governance decision is yours. Add only stable concepts that are in force and before their review date. 2. Your instructions ask for citation and abstention, but nothing enforces them. In KSoR's served route, the server over MCP, governance filters what the worker can retrieve. There, abstention is enforced once a floor, the line below which the record declines to answer, has been calibrated, or measured and set.[^ksor] Part IV of this book builds that served route. 3. Approved knowledge can still be wrong or out of date. That is why it has a named owner and a review date. [^ksor]: KSoR, the Knowledge System of Record, Panaversity.