Lesson 4.74.7 The governance rule

In everyday life. A gym's rule says members under 16 need a parent. The entry gate at the front desk is set to check age. The rule and the gate are different things.

The book's governance rule splits the job of governing a worker between the three owned systems of record: KSoR governs what an AI Worker may know. DSoR governs what it may do. SSoR governs what it may take as true right now.

May know means may answer from. The model knows many things, but the worker answers from the record or abstains. In plain words, SSoR governs what is true right now about the work: where each matter stands, and what it waits for. The facts underneath, such as whether an approval exists, belong to the company's systems, read through DSoR (4.3).

The first edition's rule was that every worker runs against a system of record.¹ That rule survives, split in three, because knowledge, action and the state of the work need different governance. Knowledge changes by approval, and when the record has no answer, the worker abstains. Actions pass fixed checks, and a failed check means a refusal or a wait for a person. The state of the work changes only by recorded steps. So the worker takes where a matter stands from its case file, never from an email or from its own memory.

KSoR and DSoR meet where a policy becomes a control. A policy is a sentence, and software cannot enforce a sentence. At Brightline it would work like this.

1. In the KSoR. AP policy v3 says invoices over $5,000 need the controller's approval before payment. It has an owner, Dave, and a version, approved September 1.
2. Turned into a control by people. One person turns the sentence into a control on the payment operation: amount over $5,000, require the controller's approval. A second person reviews it. The control records which policy version it was built from.
3. In DSoR. The $7,800 Midwest Packaging payment waits until Dave approves it from his own login. The evidence records the control, the policy version and his approval.

At Brightline this is Dave and IT, and a handful of controls on two operations, payment and status, set in the accounting system's approval step and the product's settings.

Figure 4.4. A policy becomes a control. An audit can go back from any action to the exact policy version.

No system does another's job. KSoR never decides whether an action is allowed, and DSoR never decides what the policy is. Only the SSoR keeps each matter's case file. When the policy changes, the DSoR specification requires the old control to be marked stale and its owner told, never switched off without telling anyone.² The Role Contract is the source of every control, and at run time the control wins, because software runs controls, not sentences. A contract line that no control enforces yet is a target, not yet in place, and the lab asks you which one Dave's rule is.

In 10-80-10 terms, people write the owned rules and controls in the first 10 percent, done once and in advance for a worker that never stops (Chapter 3). The worker runs in the rented layers through the middle 80, run after run, and adds each step to the case files as it works. People read the owned layers' citations and evidence in the final 10, at the times they choose: the approval queue, the flags, and Dave's Thursday review.