4.6 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 two owned systems of record: KSoR governs what an AI Worker may know. DSoR governs what it may do.

The first edition's rule was that every worker runs against a system of record.¹ That rule survives, split in two, because knowledge and action 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 two 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.

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

Neither system does the other's job: KSoR never decides whether an action is allowed, and DSoR never decides what the policy is. 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.²

In 10-80-10 terms, people write the owned layers in the first 10 percent. The worker runs in the rented layers in the middle 80. People read the owned layers' citations and evidence in the final 10.