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

---
type: Document
title: "4.7 The governance rule"
description: "How the three owned systems of record split one job between them, and how a written policy becomes a control that software can enforce."
status: stable
order: 104.7
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-12T23:51:49Z
chapter: "04"
part: I
expert_status: required
concepts: [ "4.7" ]
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-12T23:51:49Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:2f1e14f2a0f11dbc37eb5856ca9b7d35b4ce4894da74c3328cf61a3c17c03861
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 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.**

The first edition's rule was that every worker runs against a system of record.[^v1-thesis] 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.

![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.*

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