Lesson 4.64.6 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. Rented here means rented from the AI vendor, or run yourself with open-source tools. Either way, it is replaceable. The accounting system is another vendor's product, but it is the company's record, and it stays when the AI vendor changes. For a one-person business the line holds too: the spreadsheet and the folder of invoices sit below it, if you can take them with you.

Rented, so replaceable.

• the model and the tier you pay for
• the harness or hosted runtime that runs the worker
• the apps, chat channels and their connectors
• the scheduling features
• the chat history the product keeps

Owned, so under the company's control.

• the Role Contract, and the standing instructions written around it
• the KSoR, its approved knowledge with versions and owners
• the SSoR, each matter's case file
• the DSoR's controls, approvals and evidence
• the 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. A shared project fails two of those four. It keeps no versions with an approver, and the product's data export carries your conversations, not the project's instructions, as 4.8 records. That is why a project is a rented place, however much you control it. A repository of policy pages with versions, owners, approvals and a clone passes all four. The same four marks apply to the SSoR's case files. 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 and is not yours to decide, such as models and harnesses, and to own the things that record how the company works, however often they change.¹

A home and its copies. Every owned thing has one home the company governs, with versions, an owner and an export, and it may have as many copies in rented places as the runs need. Every run loads a copy of the Role Contract and its standing instructions into the runtime, and that is fine. A copy is fine while it is refreshed from the home and cites it. An item is misplaced when its only copy sits where the company does not govern it, or when the worker answers from a copy instead of the home. Wednesday's policy upload was a copy that had become the home.

Memory sits on the line. A company may rent it, as long as it passes the wipe test from Concept 4.3. On the line means the wipe test decides it entry by entry: a preference may stay rented, and a fact or a permission may not live there at all.

What a run borrows, and what it leaves behind. In a run at night, the worker borrows the rented layers: a session, a schedule, a memory. What it leaves behind, the case-file lines, the evidence and the citations, is owned. The test that follows asks whether the next run could start on another AI vendor from what was left behind.

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, schedules and memory go on the rebuild list. The Role Contract, the KSoR, the SSoR's case files, 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. Run the test upward too, when the team or another company starts to use the worker (4.10). A second question goes with the swap test. If the machine the worker ran on were destroyed tonight, what would be lost? Concept 4.9 says why the answer should be nothing that matters.

Figure 4.3. The swap test.

Apply it to Friday's list. The project instructions were the only copy of the Role Contract and its standing instructions, 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. A trigger is three things. The business event and the delay the business accepts belong to the contract. The product feature that fires is rebuilt. The pending work the fresh run reads is in the case files. 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.

Run the swap test

Pick a setup, then switch the AI vendor. Watch what carries across, what you rebuild, and what is lost.

Drawn with the pictureBrightline in October

The worker today, and where each part is kept

• Role Contract and standing instructionsThe company's own record
• AP policy v3The KSoR
• Each matter's case fileThe SSoR
• Controls, approvals and evidenceDSoR
• EvaluationsThe company's own record
• Runtime settingsThe AI vendor's product
• Channel connectionsThe AI vendor's product
• SchedulesThe AI vendor's product
• MemoryThe AI vendor's product

Switch the AI vendor

Rebuilding runtime settings, connections and schedules is normal. Only the owned things must carry across.