4.5 Rented above, owned below

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.

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.¹

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.

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.