Four Owners, One Sentence Each

"The NAS owns media bytes. Recall owns memory about the video. Ashen Reel owns playing the video. cwkPippa owns judgment."

Ownership Is the Real Architecture

When a system spans several apps, the diagram that matters isn't the call graph — it's the ownership map. Who is allowed to be the source of truth for each thing? Ashen Reel lives in a family of four systems, and almost every design decision in this whole quest is a direct consequence of keeping those four from stepping on each other's toes.

Four owners, one sentence apiece:

The NAS owns the media bytes — the irreplaceable originals.
Recall owns the memory about each video: its identity, its canonical path, its transcript, its releases and annotations.
Ashen Reel owns the act of playing, plus disposable local convenience state (resume, preferences, recents).
cwkPippa owns judgment: identity, conversation, memory, tools, model routing.

What Each May and May Not Do

The sentences imply a strict set of permissions. Ashen Reel may read the NAS bytes but never write, rename, or delete them. It may resolve and project Recall's transcript but never keep a competing copy. It may create and reset its own local state freely — because that state is convenience, not truth. And it may bind a client surface to cwkPippa but never hold a brain or a model key of its own.

Know who owns each truth, and let no one else store a second copy of it. When two systems both claim to own the same fact, they drift, and then you're writing reconciliation code forever. One owner per truth; everyone else reads.

The whole map fits on a card, and it's worth keeping one:

Each owner is a bounded context. These four aren't just apps; they're separate domains of responsibility with clear seams between them. The transcript means something specific inside Recall and is merely displayed inside Ashen Reel. Naming the boundary — and refusing to let a concept quietly become owned by two contexts — is what keeps the whole family coherent as it grows.

Why the Fourth Owner Matters

It would be easy to list three owners and forget cwkPippa — after all, a video player doesn't obviously need a brain. But Ashen Reel has a Pippa Sidekick, and the temptation to give it 'just a little' local intelligence is real. Naming cwkPippa as the owner of judgment up front is what stops that drift before it starts: the player projects and asks, but it never decides. Track 7 is entirely about honoring that fourth sentence. Name all your owners, even the one you're tempted to absorb.

Code

The ownership map — one owner per truth, everyone else reads·text

OWNER        OWNS                                  ASHEN REEL MAY     MAY NOT
-----        ----                                  --------------     -------
NAS          the media bytes                       read              write / rename / delete
Recall       video_id, path, transcript, release   resolve + project keep a competing copy
Ashen Reel   playback session, resume, prefs       create / reset    treat as archive truth
cwkPippa     identity, conversation, judgment      bind a client     hold a brain / model key

// Every 'MAY NOT' in this table is a bug someone would otherwise write
// by accident. The table exists so the accident becomes a visible no.

Exercise

Map the ownership of a system you work on. List the important facts (a user's email, an order's status, a document's latest version) and for each, name the ONE system that owns it. Then hunt for a fact that two systems both persist. That duplication is a drift bug waiting to happen — write down which one should be the owner and how the other should become a reader instead.

Hint

The dangerous pattern is 'both services keep a copy and sync them.' Sync is where drift lives. For each shared fact, pick a single owner, and turn every other holder into something that reads (or caches with a clear invalidation), never a second source of truth.

Four Owners, One Sentence Each

Ownership Is the Real Architecture

What Each May and May Not Do

Why the Fourth Owner Matters

Code

External links

Exercise

Progress

Comments 0