4.4 DSoR acts

In everyday life. A company does not hand a new AP clerk the bank password and say "pay whatever looks right." The clerk gets a desk with a login of their own and a list of what they may do. They also get a spending limit, a manager who approves large payments, and a logbook.

A DSoR, or Data System of Record, is that desk, governed, for an AI Worker. It is the layer between the worker and the company's real systems.

Its rule fits in two sentences: DSoR never takes the worker's word for anything. It checks for itself.¹ Every request to act passes the same checks.

1. Who is asking? The worker has its own identity, not a borrowed employee login.
2. Under whose authority? The worker acts for a named principal, inside limits that person was allowed to delegate.
3. Which rules apply? Limits and controls are checked by the system, not by the model.
4. Does a person have to approve? If so, the action waits until that person approves from their own login.
5. What is true right now? DSoR reads current state itself. It does not trust the state the worker reports.
6. Has this already happened? A retried request must not pay an invoice twice.

Each action leaves evidence: who asked, under whose authority, which rules ran, who approved and what happened.

The reason is not that models are careless. An agent can be confidently wrong. It can be tricked by text it reads. And it retries things a person would not. Thursday showed the first two. Through a DSoR, "approved" is not a status the worker can type. It is an event recorded when Dave approves from his own login. The lookalike email is text the worker read, so the most it can do is flag it.

DSoR in this book. DSoR is an open specification, and Part IV teaches it in depth. Until then, you set the worker's limits with the controls that products already offer: read-only access, approval steps, and no write access. Chapter 7 turns that into the Authority Envelope.