# 7.7 DSoR and the clerk analogy (/managing-ai-workers/the-authority-envelope/clerk-analogy)

---
type: Document
title: "7.7 DSoR and the clerk analogy"
description: "What a company gives a new accounts clerk, what the same safeguards look like for an AI Worker, and who provides them in Part II."
status: stable
order: 207.7
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-06T21:02:42Z
chapter: "07"
part: II
expert_status: required
concepts: [ "7.7" ]
last_verified: 2026-10-07
sources:
  - id: dsor
    title: "DSoR, the Data System of Record (Panaversity, GitHub, verified 2026-10-07)"
    resource: https://github.com/panaversity/dsor
generated:
  at: 2026-10-06T21:02:42Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87
dirty: true
ksor_version: 0.0.60
---

**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.[^dsor] 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.

![The title reads "The clerk analogy." The line below it reads "Give an AI Worker the same boundaries you would give a new accounts clerk." A table has three columns, headed "A new clerk gets," "DSoR is designed to provide" and "In Part II, you provide." Under the second heading is "Specified controls," and under the third is "Human safeguards." A login of their own: the worker's own identity, and in Part II the worker uses your account and you retain execution. A defined list of duties: authority checks on every action, and a written Authority Envelope with matching permissions. A spending limit: enforced numeric limits, and explicit thresholds checked before release. A manager's sign-off: required approvals, and a named person who reviews and releases drafts. A logbook: evidence for every action, and a task record checked against source evidence. A dark banner reads: the design principle, verify independently. DSoR is specified to check system state, identity and authority rather than rely on the worker's claims.](img/clerk-and-dsor.png)

*Figure 7.7. The clerk analogy.*

DSoR's specification adds one rule: it never takes the worker's word for anything.[^dsor] 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.

[^dsor]: DSoR, the Data System of Record, Panaversity.