~13 min · single-fan-in, seam, architecture, the-loop
Level 0Tool Renter
0 XP0/36 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 v2 — the workspace end of the loop: the drawing stays in Dad's hand, Ember answers underneath, and every candidate carries the revision it came from.
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 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.
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.