7.7 DSoR and the clerk analogy

In everyday life. A bank teller, the person at the bank counter, checks your ID and your balance before giving you cash, however confident you sound.

DSoR, the Data System of Record, is the layer between an AI Worker and a company's real systems. Its specification, its detailed written design, starts from an ordinary office fact.¹ A company does not hand a new accounts clerk the bank password and say "pay whatever looks right." The clerk gets five things: a login of their own, a list of what they may do, a spending limit, a manager who approves large payments, and a logbook to record what they do. Figure 7.7 matches each one to what DSoR's specification provides. It also shows what takes its place in Part II of this book.

Figure 7.7. The clerk analogy.

DSoR's specification adds one rule: it never takes the worker's word for anything.¹ As specified, it reads the current state of the real systems itself. It checks who is asking and with what authority. And it makes sure nothing runs twice by accident.

The policy of Brightline, the company in this book's story, already works this way in one place. Section 4.2 of Brightline's payment policy counts an approval only when Dave, the controller, records it from his own login. So a message saying "approved" counts for nothing. That control checked identity and authority itself, which is why, in this chapter's story, the tricked worker could not get anything paid.

In Part II there is no DSoR between the worker and Brightline's systems. You take its place: you keep execute, the rung where actions are taken, for yourself, approve from your own account and read the task record. DSoR is an open specification, and Part IV teaches it in depth.

So write the envelope, the worker's written limits, so that a system can enforce it: every action named, every threshold a number, every approver named by role, such as the controller. Then it can become DSoR's rules without being rewritten.