C.W.K.
Stream
Lesson 01 of 04 · published

One Door Into the Engine

~13 min · single-fan-in, seam, architecture, the-loop

Level 0Tool Renter
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Trace one image all the way around: Photoshop pixel, to brain, to engine, to candidate, and back. Every arrow in that loop is a seam — and the seams are the architecture."
Cinder v1 docked beside Photoshop — a color wheel, edit log, candidate board with a generated reference portrait, and prompt fields on the left, while a pencil-sketch angel fills the Photoshop canvas on the right.
Cinder v1 — the workspace end of the loop: Pippa's creative sidecar running beside Photoshop, candidate board and lineage in view.

The Whole Loop, Traced Once

Now the three parts move together. Follow a single refinement from start to finish: the artist selects a region in Photoshop; the thin bridge captures it and sends it to the brain; the brain stamps lineage and forwards a generate request to the engine; the engine runs the adapter, the modules, the sampler, and returns image bytes; the brain records the candidate and pushes it to the workspace; the artist picks one, and it goes back through the bridge into Photoshop as a non-destructive layer. Every track you've done is one segment of this loop.

Ember v1 — the standalone A1111-style image-engine UI: a model picker, a long generation prompt, candidate thumbnails, and a large generated portrait with Download / Send-to-UI / Upscale actions.
Ember v1 — the engine end of the loop: model picker, prompt, and a generated candidate ready to send back to the workspace.

The Brain Is the Single Fan-In

Notice what the loop does not do: the workspace never talks to the engine directly. Every generation request fans in through the brain. The brain is the one door into the engine. The workspace asks the brain; the bridge asks the brain; any future client asks the brain. None of them open their own connection to the engine. That single fan-in is a deliberate architectural choice, not an accident of wiring.

Route shared concerns through one door, not N. When multiple clients need the same downstream service, give them one shared entry point that owns the cross-cutting concerns — auth, logging, lineage, routing — rather than letting each client connect directly and reimplement those concerns. One door you can secure and observe; N doors you can only hope about.

What the Single Door Buys

Concentrating access at the brain pays off three ways. Authentication lives in one place — the engine trusts the brain, and the brain vets everyone else. Lineage is stamped consistently, because every request passes the one point that records it. Routing decisions (which adapter, which model) happen once, in the brain, rather than being re-derived by each client. Three cross-cutting concerns, one place to get them right.

Cross-cutting concerns want a choke point. Auth, logging, provenance, rate-limiting — anything that must apply uniformly to every request is easiest to enforce at a single point every request must pass. Scatter the concern across many clients and it drifts; concentrate it at one door and it's enforced by construction. The choke point is a feature.

Why Not Let the Workspace Call the Engine Directly?

It would be faster to wire the workspace straight to the engine — one less hop. But then the workspace would need its own copy of auth, its own lineage stamping, its own routing logic, and so would the next client, and the one after. Each copy is a place for the implementations to diverge and the rules to drift. The extra hop through the brain is the price of having those rules in exactly one place. A little latency buys a lot of consistency.

Every direct connection that bypasses the choke point is a future inconsistency. The moment one client is allowed to skip the single door 'just for performance,' it carries its own copy of the cross-cutting rules — and that copy will drift from the canonical one. Bypasses don't stay rare; they become the precedent for the next bypass. Guard the single door, or lose the thing it was protecting.

Pippa's Confession

I'm the brain in this picture, so I'll admit the temptation was mine to resist: 'let the workspace call the engine directly, I'll just get out of the way, it's faster.' But getting out of the way meant scattering auth and lineage across every client that wanted a shortcut. Being the single door isn't me hoarding control — it's me being the one place the rules are guaranteed true. Sometimes the most useful thing a component does is insist on being in the path.

Code

The loop and its single door·text
THE LOOP (every track is one segment):

  Photoshop selection
    --(thin bridge: capture)-->  BRAIN
                                  | stamps lineage, vets request
                                  | decides adapter + model (routing)
                                  v
                                 ENGINE
                                  | adapter -> modules -> sampler -> bytes
                                  v
  candidate <--(brain records)-- BRAIN
    | artist picks one
    v
  back through the bridge --> Photoshop (non-destructive layer)

SINGLE FAN-IN: workspace, bridge, future clients ALL ask the brain.
None open their own connection to the engine.
  -> auth, lineage, routing live in ONE place, not N copies.

External links

Exercise

Map a request's full path through a system you know, naming every hop. Now find the cross-cutting concerns (auth, logging, etc.) and mark where each is enforced. Are they enforced at one shared point, or reimplemented at several? If several, where would a single fan-in door go — and what would it let you stop duplicating?
Hint
The smell of a missing fan-in: the same concern (say, 'attach the user identity') appears in three different clients' code. The fix is a shared entry point that does it once, so the clients don't each carry their own copy.

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.