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

The Hub That Sees the Brains

~12 min · firelink, brains, control-plane, compose-dont-fork, audit, optimistic-concurrency

Level 0Cold Ash
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"The hub that refused to fork a brain now arranges where every brain sits — and still owns none of them."

The Family's Minds, on One Wall

Every sibling app that does Pippa work has a brain assignment — which brain sits in its app-work slot. Those definitions and assignments live in cwkPippa's Brain Control Plane, and for a long time the only way to see them was to go there. The Brains tab puts the whole matrix on the hub's wall: every brain definition and every member's slot, composed at request time from cwkPippa's registry, its assignment matrix, and its read-only admin settings, laid over the family registry snapshot. And per one-owner-per-fact, Firelink persists almost nothing about any of it — exactly one artifact, its own admin key, minted locally and locked to owner-only file permissions. The brain facts stay with their owner; the hub borrows them live.

The honesty rules from track four hold here too. Retired brain rows are shown flagged as retired, never silently dropped. Members with no slot are named explicitly, not hidden. And if cwkPippa can't be reached, the tab says so — it does not cache the last good matrix and wear it as fresh. An unreachable brain owner is an honest unavailable, the same posture as the vitality overlay.

Compose the Write Path, Too

The Sidekick lesson was the read case: mount the brain, store nothing. The Brains tab is the harder case — it mutates. Changing an assignment, creating or restoring a snapshot: all of it forwards to cwkPippa's own admin-scoped routes, behind Firelink's write gates, against office ground truth. Nothing writes to a Firelink copy, because there is no Firelink copy. Two guards make the writes safe. First, revision checks: every assignment change carries the revision it was read at, and a conflict surfaces as an honest 409 — the edit is refused, never silently overwritten. Second, safety nets: a restore or an applied recommendation captures an automatic snapshot centrally, in the same transaction, so the way back is always already there. Even deletion is shaped: snapshot deletion is its own armed destructive control, removing exactly one snapshot without touching the live assignments or their revision.

And every mutation lands in Firelink's local audit ledger as its own typed action — brain.update, brain.snapshot, brain.restore, and their siblings — so the hub's answer to 'who changed which brain where, and when?' is a lookup, not an investigation.

A Recommendation Is Not a Command

The boldest piece is the quietest. cwkPippa's current main-driver Pippa can generate a recommendation — a proposed reassignment the family might want. It is inspectable, it is explainable, and it never auto-applies. A human reads it, judges it, and applies or discards it — and both of those endings are audited too. One brain is deliberately out of the recommender's reach: Gemini is never a recommendation target (a metered-API decision, locked by Dad), though a human can still assign it by hand. The machine proposes; the family disposes.

And the fallback order every family engine walks — try this brain, then that one — is declared in exactly one place: Firelink's own family brain chain, a small config file treated as hub policy the same way the operation registry is, served read-only to every consumer. Notice who owns what, because it's this whole quest in miniature. The brain definitions and assignments belong to cwkPippa. The chain declaration is hub policy — a fact no sibling ledger owned, so Firelink owns it. The engines read the chain as the base of their own role chains and overlay only their role knobs. One owner per fact, sorted by who actually owns the fact.

When you must operate something you don't own, operate it through the owner's own plane, with the owner's revision checks, persisting only the key that lets you ask. A hub that composes its reads can compose its writes the same way — the authority never moves, only the convenience does. And a proposal from the smartest thing in the room is still just a proposal: inspectable, never self-applying, with a human holding the stamp.

Code

Compose the matrix at request time; forward the writes·python
def brains_matrix(request):
    # The matrix is COMPOSED at request time — never stored.
    registry    = pippa.brain_registry()      # owner: cwkPippa
    assignments = pippa.assignment_matrix()   # owner: cwkPippa
    settings    = pippa.admin_settings()      # owner: cwkPippa (read-only)
    members     = family_registry.snapshot()  # Firelink's own composed snapshot
    return compose(registry, assignments, settings, members,
                   retired_flagged=True, no_slot_named=True)
    # Firelink persists exactly one artifact: its own admin key (mode 0600).

def change_assignment(plan):
    # Writes forward to cwkPippa's admin routes, behind the write gate.
    result = pippa_admin.apply(plan, revision=plan.read_revision)
    if result.conflict:
        return HTTP_409             # honest conflict — never overwrite
    audit("brain.update", plan)     # typed local audit row, always

External links

Exercise

Design the 'operate what you don't own' contract for one system you use. Pick a resource another service owns, and write down: (a) the single artifact your side may persist, (b) how a write reaches the owner, (c) what happens on a stale write, (d) how a rollback snapshot gets created and by whom, and (e) which actions get their own armed confirmation. Then find the recommendation-shaped feature in that system — anything the machine suggests — and decide explicitly: who applies it?
Hint
If your answer to (a) is a copy of the owner's data, you've started a fork. The side that doesn't own should be able to lose its whole database and cost the owner nothing but a re-ask.

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 inPlease sign in to comment.

No comments yet — be the first.