"A north star isn't a feature. It's the one principle you check every decision against — and module separation is the engine's."
What a North Star Is
Most architecture decisions are local: this function, that schema, this boundary. A north star is the one global principle that every local decision must point toward. For the engine, that principle is module separation: keep VAE, text encoder, backbone, sampler, and conditioning as independent units with clean interfaces — always, even when fusing them would be a little faster or a little less code.
Why This One, Above All Others
The engine could have chosen speed, or minimal code, or fewest dependencies as its north star. It chose separation because separation is what makes the engine survive the future. New model families are not a maybe; they ship every few months. A north star of speed would optimize the present and rewrite for every new family. A north star of separation pays a small ongoing tax and absorbs every new family as a bounded task. When your domain's defining feature is constant change, you make adaptability the star.
The Test Every Decision Faces
Having a north star means you have a single question to ask of any proposed change: does this keep the modules separable, or does it fuse them? A clever optimization that reaches across two modules and couples them fails the test — even if it's faster. A refactor that sharpens the interface between two modules passes — even if it adds a few lines. The star turns a thousand judgment calls into one repeated check.
When the Star Costs You
Module separation is not free. A clean interface between the sampler and the backbone means you can't reach into the backbone's internals from the sampler for a quick win. Sometimes fusing two modules really would be faster. The discipline is to pay that cost on purpose, because the alternative — a fast, fused engine that needs a rewrite when FLUX-next ships — is the exact corner the whole project exists to escape.