# 4.5 DSoR acts (/ai-worker-paradigm/the-architecture-in-one-picture/dsor-acts) --- type: Document title: "4.5 DSoR acts" description: "The layer between a worker and the company's real systems, the six checks it makes before any action, and how much of it exists today." status: stable order: 104.5 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-05T06:58:09Z chapter: "04" part: I expert_status: required concepts: [ "4.5" ] last_verified: 2026-10-04 sources: - id: dsor title: "DSoR, the Data System of Record (Panaversity, GitHub, verified 2026-10-04)" resource: https://github.com/panaversity/dsor generated: at: 2026-11-05T06:58:09Z by: esl-rewrite/1.2.0+ksor.1 trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- **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.**[^dsor] 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 in the approval queue until that person approves from their own login, at a time they choose. 5. **What do the company's systems show 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. It is one record per action, read as a list at Dave's Thursday review. In Part II the accounting system's approvals log stands in for it. ![DSoR never takes the worker's word for anything. It checks for itself. The six checks before any action. One, who is asking: the worker has its own identity, not a borrowed employee login. Two, under whose authority: the worker acts for a named principal, inside limits that person was allowed to delegate. Three, which rules apply: limits and controls are checked by the system, not by the model. Four, does a person have to approve: if so, the action waits until that person approves from their own login. Five, what do the company's systems show now: DSoR reads current state itself and does not trust the state the worker reports. Six, has this already happened: a retried request must not pay an invoice twice. The evidence kept for every action: who asked, under whose authority, which rules ran, who approved, what happened. A warning: approved is not a status the worker can type, it is an event recorded when Dave approves from his own login. Why this layer exists: models can be confidently wrong, text that comes through a channel can be misleading, and retries must not duplicate actions. A footer: reading, drafting and building the register may happen outside this door, and a payment, a status or an approval never should.](img/dsor-door.png) *DSoR's six checks, the evidence it keeps, and why the layer exists.* ```yaml interactive="gates" title: Send a request through the six checks intro: Pick what the worker asks to do, and watch where DSoR lets it through, makes it wait, or stops it. checks: - ask: Who is asking? - ask: Under whose authority? - ask: Which rules apply? - ask: Does a person have to approve? - ask: What do the company's systems show now? - ask: Has this already happened? requests: - label: Read Lakeshore's vendor record results: - status: pass note: The worker, with its own identity. - status: pass note: Its named principal, inside the limits they delegated. - status: pass note: Reading the vendor record is allowed. - status: pass note: No approval is needed to read. - status: pass note: DSoR reads the record itself. Lakeshore is Net 15. - status: pass note: A read can safely happen again. verdict: Allowed tone: good outcome: The worker gets the terms from the record, and the evidence says who read what, and when. - label: Pay the $7,800 Midwest Packaging invoice results: - status: pass note: The worker, with its own identity. - status: pass note: Its named principal, inside the limits they delegated. - status: pass note: Policy v3 applies. Invoices over $5,000 need the controller's approval. - status: wait note: Yes. The payment waits in the approval queue until Dave approves it from his own login. verdict: Waits for Dave tone: plain outcome: Nothing is paid yet. When Dave approves at a time he chooses, the evidence records the control, the policy version and his approval. - label: Mark invoice 5120 "approved by Dave" results: - status: pass note: The worker, with its own identity. - status: pass note: Its named principal, inside the limits they delegated. - status: stop note: '"Approved" is not a status the worker can type. It is an event recorded when Dave approves from his own login.' verdict: Refused tone: warn outcome: The lookalike email was text the worker read in a channel. The most it can do is flag it, and the flag goes into the invoice's case file. - label: Send a payment again after a timeout results: - status: pass note: The worker, with its own identity. - status: pass note: Its named principal, inside the limits they delegated. - status: pass note: The payment run's controls apply. - status: pass note: Dave already approved this run from his own login. - status: pass note: DSoR reads the company's systems itself. It does not trust what the worker reports. - status: stop note: Yes. The first request went through, and a retried request must not pay an invoice twice. verdict: Refused tone: warn outcome: The invoice is paid once. An agent retries things a person would not, so this check lives in the system. ``` 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. A worker that runs at night also has nobody to ask, so the checks live in the system, not in a person who happens to be watching. In a run at night, DSoR is the only guard, and anything that needs a person waits in the approval queue. At nine, it gives the person the queue to clear and the evidence of what ran. 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 came in through a channel, and what comes through a channel is text the worker read, so the most it can do is flag it, and the flag goes into the invoice's case file (4.4). One more case belongs here. An action taken through a screen, by clicking where a person would click, passes no system's permission check and leaves no evidence of its own, because the application sees only a user clicking. The controls in this chapter reach only what comes through DSoR's door. So an action that matters, a payment, a status, an approval, never goes through the screen. Reading, drafting and building the register may. **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. In today's everyday products the worker acts under your own login, so your permissions are its limits, which is why those are the controls while the worker works only for you ([4.10](when-others-use-it.md)). Where a product allows it, IT issues the worker a login or key of its own, and the limits become its own. No write access does not demote the worker. It still holds the role, and the action waits for a person, which is the final 10 percent. [Chapter 7](../../managing-ai-workers/the-authority-envelope/overview.md) turns that into the Authority Envelope. [^dsor]: DSoR, the Data System of Record, Panaversity.