9.4 Continuity between runs: SSoR is the handoff

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.

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.¹ 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.¹
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.

Figure 9.4. SSoR is the handoff. It shows the runs as they should have gone.