# 9.4 Continuity between runs: SSoR is the handoff (/managing-ai-workers/work-that-runs-without-you/continuity-between-runs) --- type: Document title: "9.4 Continuity between runs: SSoR is the handoff" description: "How a run that starts fresh learns what earlier runs found: the records it reads first, and why the SSoR record, not a chat, is the handoff." status: stable order: 209.4 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-10-08T06:12:34Z chapter: "09" part: II expert_status: required concepts: [ "9.4" ] last_verified: 2026-10-08 sources: - id: ssor title: "SSoR, the State System of Record (Panaversity, GitHub, verified 2026-10-08)" resource: https://github.com/panaversity/ssor generated: at: 2026-10-08T06:12:34Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:2f1e14f2a0f11dbc37eb5856ca9b7d35b4ce4894da74c3328cf61a3c17c03861 dirty: true ksor_version: 0.0.60 --- **In everyday life.** Think of a shared logbook at a front desk. Each shift reads it at the start and writes in it at the end. Nobody relies on what the last person happens to remember. **What you will learn.** How a run that starts with no memory learns what earlier runs found: from records it reads first, never from a chat. You practice it in steps 3 and 4 of the lab. **Why it matters.** A run that does not know about last week can pay what should be held. What one run learns has to live somewhere that every later run reads. A run is one time a job does its work. A fresh run is like a new person who arrives for a shift with no handoff. Nobody tells them what happened before. Chapter 8 named five places an answer comes from: context, memory, **SSoR**, KSoR and DSoR. SSoR is the State System of Record, KSoR the Knowledge System of Record, and DSoR the Data System of Record. A run that will start fresh needs four of them, all but memory, written down before it begins. | A run needs to know | Where it is kept | | --- | --- | | What its job is and where its exits are | The standing spec, loaded into the run's context each time | | What the rules are | KSoR: the approved concepts | | Where each **matter**, one piece of work, stands, and how it got there | SSoR: the record of each matter, its case file | | What is true right now in the systems | The systems themselves, read fresh. DSoR, as specified, is the door to them. In this chapter's lab, it is the register, the accounting system's export of invoices | The other place, memory, is not in the table. A run cannot rely on what a product chose to remember. **SSoR**, the State System of Record, keeps one record per matter: a payment, a vendor request, a dispute. Each record says where the matter stands, what was tried, what is pending (still waiting to happen), and the evidence for each step. SSoR's own design says it simply: the case file is the handoff.[^ssor] A new run, or a person, can continue a matter with no chat history and no notes from the last run. At Brightline, the book's example company, the Tri-County bank-detail request was a matter. It had a start: the email on November 17, reported by a sender with no authority over Brightline's records. It had a pending step: Maria's callback, her call to Tri-County on the number already on file. And it had a rule that applied while it was open: policy 5.3, which holds every payment to that vendor until the request is checked. Maria's record held it. But the run's instructions never named the record, so the run never read it. If they had named it, Thursday's note on November 19 would have said "recommend holding invoice 5207 under 5.3, callback pending." Three rules keep the handoff reliable. 1. **Read the record first, and update it before anyone acts.** Each run opens the matters it works on before it does anything. Each run ends by proposing new entries: what it found, what it flagged, what it is waiting for. 2. **The record is not the truth now.** SSoR shows the latest known, on the date it was recorded. Before anything is paid or changed, current status comes from the system that holds it. Never act on SSoR alone.[^ssor] 3. **The record does not run the clock.** SSoR remembers that a callback is pending. The runtime decides when the next run happens. Reminders, retries and schedules belong to the runtime. SSoR is a published design. In Part II you keep the record by hand. The run reads one file at the start and lists proposed entries at the end. A person checks those entries and adds them. ![The title reads "SSoR is the handoff between runs." The line below it reads "Each run reads the records it needs. People review proposed updates." Panel 1, "Read first," shows four sources: the standing spec, the job and its exits. KSoR, approved rules. SSoR, matters, history and pending steps. Current systems, read operational status fresh. Panel 2, "Each run reads all four sources," shows three fresh runs. On November 12, the run says "Draft the payment review. M-031 is not open yet." On November 19, it says "M-031: callback pending. Recommend holding invoice 5207." On November 26, it says "M-031: request resolved. Include 5207 for review, verify current status before approval." Each run's dashed arrow leads to "Proposed entries, human review, updated SSoR record," which is "available to the next run." Panel 3, "Inside matter M-031: Tri-County bank-detail request," is a table of dated entries and their origin. November 17: email requests new bank details, reported. November 17: Maria confirms callback is pending, confirmed. November 19: worker recommends holding 5207 under policy 5.3, inferred. November 20: callback confirms email was not genuine, request closed, confirmed. A gold strip at the bottom reads "Latest known is not verified current. Check the system before acting. The case file carries continuity. The runtime runs the clock. In this lab, a person maintains SSoR by hand."](img/handoff.png) *Figure 9.4. SSoR is the handoff. It shows the runs as they should have gone.* [^ssor]: SSoR, the State System of Record, Panaversity.