Lesson 4.34.3 Memory remembers

In everyday life. You remember a friend's old phone number. When the contact card says something different, the card wins.

Memory is the worker's continuity: preferences, experience and where to look. It is useful. A worker can remember that Maria wants the register sorted by due date, or that one vendor sends each invoice as two PDFs. That saves people from repeating themselves. In today's products, memory belongs to a person's account or to a project, never to the worker. What a shared project remembers is what was said inside it, as 4.8 records.

Memory has one hard limit: it is never authoritative. It never overrides KSoR, SSoR or DSoR. The precedence rule, which decides who wins, is short.¹

• For knowledge, KSoR wins. If memory says the approval limit is $10,000 and the approved policy says $5,000, the answer is $5,000.
• For where a piece of work stands, SSoR wins. If the invoice's status in the register says "approved by Dave", typed in by the worker because of an email, and its case file shows it waiting for Dave's approval of the run, the case file wins.
• For current state, the company's systems win, read through DSoR. If memory says Lakeshore is Net 30 and the vendor record in the accounting system says Net 15, the answer is Net 15.
• A typed field is a claim, not a fact. A fact is current state when the system made it from its own event, such as Dave's approval from his own login or the bank's payment. A status anyone can type, such as the one the worker set, is a claim, and a claim loses to the case file's recorded steps. In the accounting system, "paid on October 20 by bank transfer" is a fact, the bank's event. "Status: approved" is a claim if anyone can set it, and a fact only if the system sets it when the controller approves from his own login.
• Memory only says where to look. A good memory entry reads "Lakeshore's terms changed in August, so check the vendor record." A bad one reads "Lakeshore is Net 30." A pointer that is true for every run, such as "terms are in the vendor record", belongs in the Role Contract's knowledge sources. Memory holds what one run learned.

Figure 4.2. Who wins when memory disagrees with the record. Memory decides nothing.

Monday's failure broke this rule. The remembered fact was true in July. Facts become stale (out of date), and memory has no owner, no approval and no version to warn anyone.² So memory must never be the only source for a fact or permission the worker acts on. Approval limits, payment terms, bank details and approvals are checked against the governed source every time. When memory and a record disagree, the record answers, and the disagreement goes into the case file, flagged to the record's owner, the AP team for a vendor record. The record may be wrong, but only its owner can change it. On that day the worker's answer is wrong and flagged, never wrong and silent.

One test, the wipe test, checks whether memory is in its place. If the memory were wiped tonight, would tomorrow's work still be correct? The worker may be slower. It re-reads the record, or waits to ask Maria again how she likes the register. But it must recover safely and never act on a guess. If wiping memory would make the worker wrong, something authoritative is stored in the wrong layer. On a product the test is literal: switch memory off, or open a chat that does not use it, and ask Monday's question again.

In a run at night, memory gives the worker a pointer to where to look, and nothing it may act on. At nine, there is nothing in memory for the person to check, which is why nothing authoritative may live there.

Chapter 8 explains in full how context, memory, SSoR, KSoR and DSoR differ.