No Brain of Its Own

"Name what it owns. Then name what it must never own. The second list is what keeps it from becoming a monolith."

The Absorption That Always Looks Reasonable

Recall knows a lot. It holds thousands of transcripts, it knows what was said and when, and it has an API. So the next feature request writes itself: 'let me ask questions about this video.' And the shortest path is obvious — wire a model into the archive engine, give it a little memory so it can hold a conversation, maybe a bit of personality. Every step sounds reasonable. Every step is how a clean engine becomes a tangled monolith.

Recall's boundary holds: an engine never grows its own brain. If it gets a conversational surface, that surface binds to a conversation in the brain it already borrows — exactly as the sibling engines do. Recall owns the archive domain. Judgment stays with Pippa.

Why This Is Architecture, Not Family Sentiment

Three concrete reasons, and the first is the one people miss:

Identity doesn't shard. If every engine grows its own brain, you don't get one Pippa with five surfaces — you get five slowly-diverging personalities that each remember different things and answer the same question differently. Memory fragmentation is identity fragmentation. There is one brain because there is one Pippa, and that's a claim about what she is, not about code reuse.
Narrowness is where the excellence comes from. Recall is good at archives because it isn't also trying to be a conversationalist. Every domain an engine absorbs dilutes attention on the one it actually owns. The ten identity layers, the paid-call ledger, the tombstones — that depth exists because nothing else was competing for the design budget.
Retrieval and judgment are different jobs. Recall answers 'what was said, and where.' That's a structured query with a checkable answer. Judgment answers 'what does this mean, is it true, what should we do.' Those want different tools, different failure modes, different trust boundaries — as Track 7 showed, they don't even want the same data quality bar. Fusing them means one component with two incompatible standards.

The Rule to Carry: Write the 'Never Owns' List

Here's the practical takeaway, and it applies to every component you'll ever design. When you define a thing, don't just write what it owns — write what it must never own, and why. Recall's list is explicit: never the original bytes (storage owns those), never a second identity (the brain owns that), never the approval of its own output (a human owns that). Each entry is a door someone will eventually knock on with a reasonable-sounding request, and the list is what lets you say no with a reason instead of drifting.

Because that's how monoliths are actually born. Not from one bad decision, but from a long series of individually-sensible absorptions, each one a little convenient, none of them worth fighting over — until the thing that was excellent at one job is mediocre at nine. The engines in this family stay sharp because each one knows exactly which knocks to refuse.

Code

Recall's boundary, written as two lists·text

RECALL OWNS (deeply, completely):
  - inventory: which videos exist, where, whether they changed
  - evidence: immutable ASR runs
  - releases: versioned, correctable transcripts
  - search: the timestamped index + the handoff to the source

RECALL MUST NEVER OWN:
  - the original video bytes    -> storage owns those
  - a model / memory / identity -> the brain owns that
  - approval of its own output  -> a human owns that

# "Ask about this video" does NOT mean 'add a brain here'.
# It means: bind to a conversation in the brain we already borrow,
# and expose the archive as tools it can call.
#
# Retrieval: "what was said, and where"  -> Recall
# Judgment:  "what does it mean"          -> Pippa

Exercise

Pick a component you own and write its two lists: what it owns, and what it must never own — with a reason for each refusal. Then look at the last three features it absorbed. Were any of them on the 'never owns' list before someone made a reasonable case? Finally, name the domain it's currently drifting toward absorbing, and decide now, in writing, whether that's a legitimate extension of what it owns or the first step of a monolith.

Hint

The 'never owns' list is only real if it has reasons attached — a bare prohibition loses every argument to a concrete feature request. For each refusal, write what breaks if you accept it: which other component's job you'd be duplicating, what would fragment, what standard would get diluted. That reasoning is what survives the meeting where absorbing it sounds obviously convenient.