The Engine Family

"Ember is to images what Recall is to video memory."

One Brain, Many Engines

Recall didn't appear alone. It's the newest member of a family of engines that all orbit one brain. The shape is worth memorizing because it explains what Recall is allowed to be:

Pippa (cwkPippa) — the brain. Identity, conversation, memory, routing. There is exactly one.
Ember — the image engine. Owns model loading, sampling, generation.
Cinder — the creative workspace. A canvas that binds to the brain.
Bonfire — the music-learning engine. Owns analysis and one music model.
Recall — the video-memory engine. Owns inventory, evidence, releases, and search.

Each engine owns one domain deeply and completely. None of them owns Pippa. That's the family rule, and it's the reason Recall can be ambitious about video memory without ever trying to become a second personality.

API-First: The Engine, Then Its First Client

Every engine in this family is built the same way: the engine and its API come first, and the user interface is just the first client that talks to it. Recall's React console is not Recall — it's the first thing that calls Recall's API. The search endpoint, the archive endpoint, the inspection endpoint: those are the product surface. The console renders them.

Why insist on this order? Because a second client is always coming. Today it's a web console. Tomorrow it might be Pippa herself calling Recall as a tool, or a command-line batch runner, or a future mobile surface. If the UI owned the logic, every new client would have to re-implement it. Because the engine owns the logic, every new client is thin. You'll see the same discipline pay off in Track 2, where a long-running worker and a web browser are both just clients of the same control-plane API.

No Brain of Its Own

Here's the boundary that keeps the family sane: an engine never grows its own Pippa. If Recall one day gets a "ask about this video" feature, it won't stand up its own model, its own memory, its own identity. It will bind to a cwkPippa conversation — borrow the one brain — exactly the way Cinder and Bonfire do. Recall owns the archive; Pippa owns judgment. Mixing those is how a clean engine turns into a tangled monolith, and the whole family is designed to never let that happen.

Code

The family, as ownership (not code)·text

cwkPippa   → the brain        (identity, conversation, memory)
  ├─ Ember   → image engine    (owns generation)
  ├─ Cinder  → workspace       (binds to the brain)
  ├─ Bonfire → music engine    (owns one music model)
  └─ Recall  → video-memory    (owns inventory + evidence + search)

Rule: each engine owns ONE domain, and NONE of them owns Pippa.
A "talk to it" feature binds to a cwkPippa conversation —
it never grows a second brain.

Exercise

Take any tool you use that has both a UI and (maybe) an API. Ask: if the UI vanished tomorrow, would the useful logic survive? Could a script do what you do by clicking? If yes, the engine owns the logic and the UI is a client. If no, the logic is trapped in the interface. Write down which side of the line your tool is on — and what it would take to move the logic down into an engine.

Hint

A quick test: is there a documented way to do the tool's core job without a human clicking? A search API, an export endpoint, a CLI. If the only path is the UI, the logic and the interface are fused — which is exactly what 'engine-first' is built to avoid.