# 4.5 Rented above, owned below (/ai-worker-paradigm/the-architecture-in-one-picture/rented-and-owned)

---
type: Document
title: "4.5 Rented above, owned below"
description: "Which layers a company rents and which it must own, and a test that shows where each part of a worker really lives."
status: stable
order: 104.5
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.5" ]
last_verified: 2026-10-04
sources:
  - id: v1-operating-layer
    title: "The Agent Is the Operating Layer (Panaversity, first edition, verified 2026-10-04)"
    resource: https://agentfactory.panaversity.org/docs/ai-operating-layer
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.** You rent an apartment, but your documents and your keys to your own safe go with you when you move.

Chapter 2's rule stays true for the top two layers: never define a worker by its runtime or by its channel.

This chapter adds the line that runs across the picture. **Rented layers sit above it. Owned layers sit below it.** The book's ownership rule says the same: **the platforms are rented. The knowledge and the controls are yours.**

| Rented: replaceable products and platforms | Owned: under the company's control and accountability |
| --- | --- |
| Models and their tiers | The Role Contract |
| Harnesses and hosted runtimes | The KSoR: approved knowledge, versions, owners |
| Apps, chat channels and their connectors | DSoR controls, approvals and evidence |
| Scheduling features | Review contracts and evaluations |

Owned means controlled, not self-hosted. A company may run its KSoR on a paid service and still own it, because it controls the policies, versions, permissions and exports. The DSoR controls are owned too, even when a product's settings enforce them. This book's preferred strategy is to rent what changes fast, such as models and harnesses, and to own the things that record how the company works.[^v1-operating-layer]

**Memory sits on the line.** A company may rent it, as long as it passes the wipe test from Concept 4.3.

The **swap test** checks where things are really kept. Imagine replacing the AI vendor tomorrow. Write two lists: what you would rebuild, and what you would carry across. Runtime settings, channel connections and memory go on the rebuild list. The Role Contract, the KSoR, the DSoR controls and the evaluations must carry across with their meaning unchanged. Their connections may still need rework and retesting. If the carry list is short, owned things are stored in rented layers.

![Two columns. On the left, the rebuild list: model and runtime settings, channel connections, schedules and trigger setup, memory. On the right, the carry list, whose meaning stays the same: Role Contract, KSoR, DSoR controls and evidence, review contracts and evaluations. Below are three items from Brightline's Friday list: the project instructions, the policy upload and a trigger set as a time, not a business event. Each has an arrow to the owned place where it belongs: the Role Contract, one approved policy in the KSoR, and a Triggers line in the Role Contract.](img/swap-test.png)

*Figure 4.3. The swap test.*

Apply it to Friday's list. The project instructions were the Role Contract, stored inside a rented product. The policy upload was a copy of knowledge that belonged in a KSoR. The scheduled task was runtime configuration, so rebuilding it is normal, but its trigger belongs in the contract. The memory could be left behind, if it passed the wipe test. Dave could not answer IT because three owned things were stored in rented places.

[^v1-operating-layer]: The Agent Is the Operating Layer, Panaversity, first edition.