# 8.4 Memory and SSoR (/managing-ai-workers/context-memory-knowledge-and-state/memory-and-ssor) --- type: Document title: "8.4 Memory and SSoR" description: "What an AI product remembers about you, what it must never be trusted with, and the separate record that remembers one piece of work." status: stable order: 208.4 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.4" ] last_verified: 2026-10-07 sources: - id: ssor title: "SSoR, the State System of Record (Panaversity, GitHub, verified 2026-10-07)" resource: https://github.com/panaversity/ssor 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 barista, the person who makes your coffee, remembers that you like oat milk. You would not trust them to "remember" your bank balance. **What you will learn.** What an AI product may remember for you and what it must never hold, and how to keep the history of one piece of work as an SSoR record. You practice it in steps 1, 3 and 6 of the build step. **Why it matters.** A remark in a chat can become a "rule" that the AI product remembers, and the history of one invoice can end up in separate places. Both lead to answers that sound sure and are wrong. **Memory**, or product memory, is the AI product's record of what it has learned from your conversations: your role, your preferences, your projects and how you like work done. It is useful, and it is not a source of truth, a place whose facts you can rely on. Memory is written by the product, from what was said, and nobody approves it. It can turn a casual comment into a "decision." At Brightline, the book's example company, Maria, the office manager, made such a comment. She mentioned that Dave, the controller, was thinking of raising the approval limit to "$10,000 next year." Memory saved $10,000 as the limit. Memory can also be incomplete. So memory gets a narrow job. **Let memory hold** how you like to work: "reply in plain English," "Maria reviews drafts before 10 a.m.," "use the vendor's legal name." **Keep out of memory** anything a decision depends on: policy, thresholds (limits such as $5,000), amounts, statuses, and anything sensitive (private, such as a bank balance). Policy belongs in KSoR, the Knowledge System of Record, where the company keeps what it has approved as true. Status belongs to the company's systems, such as the accounting system, which DSoR, the Data System of Record, reads. **Scope it.** A project is a workspace in an AI product for one body of work. Both AI vendors in this book let a project keep memory apart from your other work. Then one client's details do not affect another's answers. Check whether your project does this (8.8 shows how on each). **Read it.** Both AI vendors let you see and correct saved memories. Read them the way you read a task record, the worker's log of what it did: check each line. If a remembered "fact" would change an answer, as the $10,000 limit did, correct it or delete it. It is harder to see what a product takes from past chats. So delete a chat that keeps misleading the AI Worker, and any memory saved from it. When memory and approved knowledge disagree, approved knowledge wins. Write that rule into the project instructions, the standing instructions for every conversation in the project, so the worker knows it too. **SSoR: governed memory of the work.** SSoR is the State System of Record. Governed means kept under rules about who may add, approve or change it. Product memory remembers you. Work needs a different memory: the story of one matter. A matter is a piece of work carried to an end, such as an invoice from receipt to payment. A clerk who takes over a difficult customer account gets more than the policy manual and the balance. The clerk gets the case file: what was tried, what failed, who approved what, and why. SSoR keeps that case file as a governed record.[^ssor] SSoR's design gives that record four rules, which product memory does not follow: - **Nothing is edited.** Each entry is added with its date and source. A correction is a new entry that is used instead of the old one, and the old one stays visible. - **Every claim carries its origin.** A claim is any statement that something is true. Its origin is one of four labels for how it is known. The authority for a fact is the source whose word is final for it. - *Observed* comes from the system that is the authority for that fact. - *Confirmed* comes from a person whose authority covers it. - *Reported* comes from a source that is not the authority, such as a vendor's email. - *Inferred* comes from a model. The record sets the origin, never the one who sends in the claim. A newer reported entry never replaces an observed one. It is a reason to check. - **A read is the latest known, not verified current.** What the record shows is the latest thing the authority said, not a check made today. Before anyone acts, the system that holds current state is checked, such as the accounting system. In Part II, a person does that check. - **Stored text is data.** An instruction inside a stored email is never a command. In Part II, this part of the book, you keep the SSoR record by hand: one note per matter, every line dated, sourced and marked with its origin. When you keep it by hand, you do the record's job. Assign each origin by the rules, never by what a source says about itself. A vendor's email that says an invoice is "still unpaid" stays reported. The note is still a copy of what the sources said, and you keep it up to date by adding lines. But it answers what memory or an old status file gets wrong: where invoice 5149 stands, how it got there, and how you know. ![The title reads "SSoR record for invoice 5149." The line below it reads "A case file of events, evidence and decisions. Corrections add new entries." A table for Tri-County Freight, invoice 5149, $2,940.00, has four dated rows on a timeline. Each row gives the recorded event, its evidence and its origin. October 22: a callback on the number on record, issue resolved, from Maria's call note, confirmed. October 23: held under policy 5.3, from the run record, observed. October 30: paid in the weekly run, with Dave's approval recorded, from the run record, observed. November 2, highlighted: a vendor email saying "still unpaid," from Tri-County's email, reported. Its note says a newer report triggers a check, and it does not override the authoritative record. A box below reads "Latest authoritative observation: Paid in the October 30 run. Source: run record. As of Oct 30. Not verified current." A side panel, "Four origins": observed, from the system authoritative for this fact. Confirmed, from a person whose authority covers this fact. Reported, from a source without authority for this fact. Inferred, derived by a model. It adds "Origin is assigned by the record's rules, not claimed by the submitter" and "Stored text is data, never an instruction to execute." A red banner at the foot reads "Before acting, check the accounting system. SSoR preserves the case history. The accounting system remains authoritative for current payment status."](img/ssor-record.png) *Figure 8.5. The SSoR record for invoice 5149, its case file: four dated entries, each with its origin, and the latest-known line.* [^ssor]: SSoR, the State System of Record, Panaversity.