# 8.7 Become a knowledge owner (/managing-ai-workers/context-memory-knowledge-and-state/knowledge-owner) --- type: Document title: "8.7 Become a knowledge owner" description: "The management job of deciding which knowledge an AI Worker may treat as approved, and five habits that keep that knowledge correct and current." status: stable order: 208.7 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.7" ] last_verified: 2026-10-07 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.** A restaurant changes its allergy policy. The manager first updates the main copy of the policy. Then the manager replaces the printed sheet at every kitchen station, and signs a checklist. **What you will learn.** The job of owning approved knowledge, and five habits that keep it correct and current. You practice it in steps 2, 5 and 7 of the build step. **Why it matters.** Approved rules change, and copies of them sit in several places. Without an owner, the copies drift apart, and the worker answers from an old one. A **knowledge owner** decides which knowledge an AI Worker may treat as approved, and is responsible for keeping it correct and current. It is a management job, not a technical one. An owner can give the daily work to a maintainer, a person who keeps the knowledge up to date. At Brightline, the book's example company, Dave, the controller, owns the AP policy concepts and approves them. AP means accounts payable, the bills a company owes, and a concept is a short file that holds the rules for one topic. Maria, the office manager, drafts and maintains the concepts. In this chapter's lab, you take Maria's role. For one concept from your own field, you are the owner. The job has five habits. 1. **One topic, one concept.** Split long documents into concepts a worker can cite, or name as its source, one topic each. Merge duplicates into one. Keep rules that depend on each other together. If a rule needs a step from another section, the concept holds both and cites both. 2. **Nothing serves until it is approved.** Drafts stay out of every project a worker answers from, the workspaces whose files it uses. Write and review drafts in a separate workspace. Mark each one as not approved. 3. **Remove what competes.** If an old file disagrees with an approved concept, take the file out of the project. Do not leave the worker to choose between them. 4. **Change once, then refresh every copy.** When Dave approves a change, edit the concept in the record first. The record is the KSoR, the Knowledge System of Record, where the approved concepts are kept. Then refresh each copy, each project's version, by its route: replace an uploaded copy, and check that a synced copy has synced. Check which approval each copy now holds, and write it down. A **refresh log** is that written record. It has five columns: concept, copy location, approval date held, refreshed by, refreshed on. 5. **Review on schedule.** Each concept has a review date. On that date, the owner confirms it, changes it or retires it, so it is no longer used. In the chapter's opening story, Brightline's AP Worker, the AI Worker that handles its bills, gave four wrong answers. Here is what changes in its project after that day: - The old onboarding notes and the October 23 status list leave the project. The notes disagreed with the policy, and the list was out of date. - The AP rules become five approved concepts. - The memory entry that gave the approval limit as $10,000 is deleted. The limit is $5,000. Dave had only been thinking of $10,000 for next year. - The project instructions say which source is the official one. - Maria starts an SSoR record for each matter still in progress, beginning with invoice 5149. SSoR, the State System of Record, keeps the case file of one matter, a piece of work such as an invoice. On November 9, Dave approves a currency rule as policy (Figure 8.8). An invoice in any currency other than USD (US dollars) now needs his approval, whatever the amount. Maria adds the rule to the invoice approval threshold concept. The same day, she removes her working rule, "Flag every invoice not in USD to Dave," from the project instructions. Now the rule has one official place. ![The title reads "One record, many copies." The line below it reads "Approve the change once. Refresh every copy. Verify which approval each holds." On the left, the KSoR record, the authoritative source, holds five concepts: invoice approval threshold, weekly payment run, duplicate invoices, bank-detail changes and capitalization. A note reads "Only approved, eligible concepts are distributed." An arrow labeled Sync leads to a synced project source: refresh from the approved source, then confirm the sync completed, verify the new approval is present, and record the refresh. An arrow labeled Upload leads to an uploaded project copy, a snapshot that must be replaced: remove the old upload, add the newly approved file, and verify and record the refresh. Below, a refresh log after the November 9 change has two rows for the approval threshold. Project 1 holds the approval of 2026-11-09, synced, checked by Maria on November 9. Project 2 holds the approval of 2026-11-09, by a replaced upload, checked by Maria on November 9. A dashed box, "Later: governed retrieval," reads "Serve knowledge through MCP instead of manually maintaining project uploads. Governance filters what the worker may retrieve." A red banner reads "A successful sync or upload is not enough: verify the approved revision reached the worker."](img/one-record-copies.png) *Figure 8.8. One record, many copies, and the refresh log after the November 9 change.* > **Contrast: a compliance research worker.** A compliance team at a mid-size bank runs an AI Worker that answers staff questions about lending rules. The hard part is that rules change over time. A rule takes effect on a set date. So the worker must answer "which version was in force on March 1?" as well as "what applies now?" The five places do different amounts of work: > > - Almost all of its value is in the KSoR. There, each regulation and each internal policy is a concept with an owner, an effective date and a source. The compliance officer is the knowledge owner. > - The worker's instructions demand a citation for every claim, and abstention when a concept says nothing on the question. > - Memory is off. > - Context is small: the question and the concepts it retrieves. > - SSoR and DSoR do little, because the worker handles no matters, no cases carried from start to end, and changes nothing. > > Same architecture, different work. > **Contrast: a customer support worker.** A support worker for an online shop is the opposite case. Each conversation is its own context: one customer, one problem, then a restart. > > - KSoR holds the return policy and the warranty terms. The support lead is the knowledge owner, and every policy change reaches the worker the same day. > - The real risk is state. Each ticket, one customer's problem, has an SSoR record that holds what was promised and tried, so a second worker does not start over. > - But answers to "Where is my order?" and "Was my refund issued?" must still come from the order system every time. They never come from memory or an earlier chat. > - Memory holds almost nothing, because remembering one customer's details while serving another is a privacy failure. > > Same architecture, different work.