~13 min · single-fan-in, seam, architecture, the-loop
Level 0Tool Renter
0 XP0/40 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Trace one image all the way around: Photoshop pixel, through one door, 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, as the loop ran when this lesson was written: 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. (Since 2026-09-21 the brain's part is played by the workspace's own service — the next lesson.)
Ember v1 — the engine end of the loop: model picker, prompt, and a generated candidate ready to send back to the workspace.
The Brain Was the Single Fan-In
Notice what that loop did not do: the workspace never talked to the engine directly. Every generation request fanned in through the brain. The brain was the one door into the engine. The workspace asked the brain; the bridge asked the brain; any future client was meant to ask the brain. None of them opened their own connection to the engine. That single fan-in was 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 paid off three ways. Authentication lived in one place — the engine trusted the brain, and the brain vetted everyone else. Lineage was stamped consistently, because every request passed the one point that recorded it. Routing decisions (which adapter, which model) happened 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. That was the argument as it stood; the next lesson is what happened when the workspace did get a door of its own — and paid exactly the cost this section predicts.
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, AS FIRST BUILT (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 (until 2026-09-21): workspace, bridge, future clients
ALL asked the brain. None opened their own connection to the engine.
-> auth, lineage, routing lived 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.