Skip to content
C.W.K.
Stream
Lesson 05 of 06 · published

Code, Execution, and State

~15 min · ownership, services, architecture, boundaries

Level 0Loose Parts
0 XP0/48 lessons0/13 achievements
0/100 XP to next level100 XP to go0% complete

Three Things That Looked Like One

Until September, this family had two places to put anything: the shared kit, for code identical by design, and the apps, for everything else. In practice a third thing had been riding inside one app. The assistant's own engine ran every generic model call the siblings needed — rewrite this text, list the available models — and the family's shared mutable state lived in the assistant's own stores: PIN sessions and their blacklist, device records, which brain each app's slot is assigned to, provider credentials and their usage ledger. A sibling that wanted a plain rewrite had to reach the assistant, persona and all, to get one.

The owner's ruling on 2026-09-21 separated three things that had been riding together:

  • Code belongs in the kit. That includes the stores, routes and clients for the shared state, and the worker that executes a generic model call.
  • Execution belongs to each owning engine. An app that needs a plain rewrite runs the kit's worker itself, in its own process, with no persona, conversation or memory loaded.
  • Shared state is the only thing that justifies a shared service. Sessions, devices, assignments and credentials have to be one, so exactly one owner holds them, and everyone else reaches that owner through a client.

And one sentence keeps this track's boundary intact: the kit stays a library and a sync owner. It does not gain an always-running server, a production database, or a hidden connection to the assistant. It ships the code for the state service; it never becomes it.

A Service Has to Earn Its Existence

The separation plan states the test plainly: an independent service is justified by shared mutable state or a credential authority, not by code reuse alone. Reuse is what the kit is for. If the only argument for a service is that several apps want the same behavior, the answer is a shared module each app runs, not a process every app must reach. A service adds a network hop, an availability dependency, and an owner that has to be up before anyone else can work. It is worth that only when the thing it holds would be wrong if there were two of it.

That is the membership test from track 1, one axis over. Track 1 asked whether a module needs to know what an app is about. This asks whether a piece of the system needs to be singular. Code passes the first test and goes in the kit. State passes the second and goes in exactly one service. Execution passes neither, and stays with whoever needs the result.

The Owner Moved; the Address Did Not

On the day of the ruling the shared state moved out of the assistant into the family's management app, as its one owner, with its own data root and lifecycle. The next day it moved again. The owner ruled that the assistant has to survive an outage of the management app, so the assistant's engine took the shared state back in process — and the separation plan, which had said that hosting the state inside the assistant's process would not satisfy its contract, now opens with a banner saying it is superseded in part. A written plan overruled by its owner says so at the top; it does not quietly keep the old sentence.

What let the second move pass without any consumer noticing was a facade. The management app kept every public and internal family route as a forwarding facade: it hands each request, with the caller's network identity and headers, to the new owner over a local-only capability, and returns the answer unchanged. Every consumer kept its address, its keys and its sessions. The management app's old state database was fenced so nothing could write to it by accident.

That was possible only because of the previous lesson. Consumers depended on an address and a written wire shape, not on which process answered. A thin client whose contract is written down can have its owner replaced underneath it in an afternoon; a client that had learned the owner's internals could not.

Give code, execution and state separate owners on purpose, and let only singular state earn a service. Shared code goes in a library every app runs. Execution stays with whoever needs the result. A service exists only for state that would be wrong if there were two copies — and when its owner has to change, a facade that preserves the address lets it change without any consumer noticing.

What It Cost, Measured the Same Evening

An independent cold review ran on the evening of the first move. The data side held: every migrated table reconciled exactly against its source, and native, web and phone delivery matched. The costs were real, and they were written down rather than smoothed over. For a while the assistant asked the state owner over the private network on every request, and settings reads took most of a second to a second and a half. One default — which cloud model a local-model brain should use — briefly had two live owners. Backups of the new state roots dropped to a single layer. And the cutover of generic model calls to the kit's worker regressed live, which is track 8's last lesson.

From that review the owner added the rule that governs every later change of this kind: the extraction exists for efficiency and must not break a single existing function. A shared rule stricter than the behavior it replaced is a broken feature in every app that used to rely on it.

Code

Three owners, and the facade that let one of them move·text
BEFORE (one engine quietly held two jobs)

  sibling apps --- generic model call ---------> assistant engine
  sibling apps --- PIN / devices / assignments -> assistant engine
                   / provider keys                (its own stores)


THE RULING (2026-09-21)

  CODE        the kit: stores, routes, clients, the model-call worker
              (a library and a sync owner - never a server, never a DB)

  EXECUTION   each app runs the kit's worker in its own process
              no persona, no conversation, no memory loaded

  STATE       ONE owner binds the stores in process (day one: the
              management app); everyone else binds a client to an
              injected address


THE NEXT DAY (owner moved; address did not)

  consumers ---> same address as yesterday
                   |
                   v
               forwarding facade   (management app; holds no state,
                   |                passes caller identity + headers)
                   v   local-only capability
               assistant engine, state in process  (the owner now)

               management app's old state DB: fenced against writes


THE TEST FOR A SERVICE
  would it be wrong if there were two of it?   yes -> one owner
  do several apps just want the same code?     -> a library they run

External links

Exercise

List the services in a system you know and, for each, write down what it holds that would be wrong if there were two copies. If a service holds nothing like that — if it exists only because several callers wanted the same behavior — sketch the library that could replace it, and what each caller would then run itself.
Hint
Credentials, sessions, rate limits, counters and assignments are the usual singular things. Formatting, validation, parsing and model calls are usually not: they are behavior, and behavior can be shipped to every caller without anyone having to be up first.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.