The Family Boundary Map

"A hub that owns everything is a hub no one else can trust. The strong hub owns almost nothing — and composes the rest."

Who Owns What

Zoom out to the whole family and the ownership map is crisp. cwkPippa owns the brain: identity, model and tool routing, the family PIN verifier, the Sidekick runtime, conversation storage, and coop. Watchfire owns the Macs: enrollment, peer identity, OS state, fleet campaigns, host liveness. The deploy tool owns native signing, bundle validation, staleness rules, and launchd installation. The repo-sync tool owns the office-to-peer fan-out doctrine. The roster owns display metadata and lifecycle; the network ledger owns hosts, ports, and URLs; each sibling repo owns its own product source. Firelink sits in the middle of all of it and owns almost none of it.

What's Left for the Hub to Own

So what does Firelink own? Exactly the hub policy that no sibling ledger owns: bundle ids, service labels, adapter ids, target ids, per-member health checks, and peer allowlists — plus its own runtime database of sessions, plans, runs, and audit. That's it. Everything else, it composes: it reads each owner's truth and assembles a live model, and it forks none of them. The hub's power comes from seeing everything, not from owning everything.

Compose, Never Fork

This is the discipline that keeps twenty-two repos from collapsing into one tangled mass. A normal Dad-and-Pippa development session is what changes product intent — the code, the architecture, the real decisions — and Firelink only ever consumes the result of that work. It never reaches back to redefine a sibling's truth. When you build a coordinator for a system of parts, the temptation is always to pull the parts' definitions into the coordinator 'so it's all in one place.' Firelink's answer: no. Leave every fact with its owner, compose them at read time, and the coordinator stays a coordinator instead of quietly becoming the thing it coordinates.

A coordinator should own only the policy no participant owns, and compose everything else from its rightful owner. The instinct to centralize all definitions 'for convenience' is how a coordinator metastasizes into a monolith. Own the seams; borrow the facts; and the system stays a federation of clear owners instead of one tangle.

Code

The boundary map: Firelink composes, forks nothing·text

  OWNER              OWNS                              FIRELINK'S BEHAVIOR
  ----------------   -------------------------------   ---------------------------
  cwkPippa           brain, PIN verify, Sidekick,      mounts + delegates;
                     routing, conversations, coop      forks none of it
  Watchfire          Macs, enrollment, OS, fleet,      consumes peer ids +
                     host liveness                     read-only liveness overlay
  deploy tool        signing, bundle validation,       invokes via adapter;
                     staleness, launchd install        never reimplements
  repo-sync tool     office->peer fan-out doctrine     invokes canonical adapter
  roster             titles, one-liners, lifecycle     decorates members
  network ledger     hosts, ports, urls                composes into surfaces
  each sibling       its own product source            observes; never edits

  FIRELINK OWNS ONLY: bundle ids, service labels, adapter/target ids,
    peer allowlists, per-member health checks + its runtime DB.
  Everything else is COMPOSED from its owner. Nothing is forked.

Exercise

Draw the ownership map for a system you know that coordinates several parts (a dashboard over microservices, an orchestrator over tools). For each fact the coordinator displays or acts on, name the true owner. Then find one fact the coordinator has quietly forked — kept its own copy of, or redefined. Describe how you'd give that fact back to its owner and have the coordinator compose it instead.

Hint

The forked fact is usually the one that was 'easier to just keep here.' Look for any place the coordinator stores a definition (not just a cache) of something a participant should own. Give the definition back; keep at most a derived, clearly-labeled view.

Who Owns What

What's Left for the Hub to Own

Compose, Never Fork

Code

External links

Exercise

Progress

Comments 0