# 4.6 The governance rule (/ai-worker-paradigm/the-architecture-in-one-picture/governance-rule)

---
type: Document
title: "4.6 The governance rule"
description: "How the two owned layers split one job between them, and how a written policy becomes a control that software can enforce."
status: stable
order: 104.6
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-05T13:02:46Z
chapter: "04"
part: I
expert_status: required
concepts: [ "4.6" ]
last_verified: 2026-10-04
sources:
  - id: v1-thesis
    title: "The Agent Factory Thesis (Panaversity, first edition, verified 2026-10-04)"
    resource: https://agentfactory.panaversity.org/docs/thesis
  - id: dsor
    title: "DSoR, the Data System of Record (Panaversity, GitHub, verified 2026-10-04)"
    resource: https://github.com/panaversity/dsor
generated:
  at: 2026-10-05T13:02:46Z
  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 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.[^v1-thesis] 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.

![A left-to-right flow in four steps. The policy sentence in the KSoR, version 3, approved September 1. A control written by one person and reviewed by a second, recording the policy version. The $7,800 payment waiting in DSoR until Dave approves from his own login. The evidence record. A return arrow shows an audit going back from the action to the policy version.](img/policy-to-control.png)

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

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.

[^v1-thesis]: The Agent Factory Thesis, Panaversity, first edition.
[^dsor]: DSoR, the Data System of Record, Panaversity.