The fractal operating model
The estate had grown past the point where a flat list of projects meant anything useful. Some of those projects were products people would eventually visit; some were engines other projects depended on; some were infrastructure nobody outside the estate would ever see directly. Treating all of them the same way — one README format, one deployment checklist — was starting to hide more than it revealed. What changed was a single doctrine: one home. Every concern the estate has — identity, security, observability, credentials — is a spine, and exactly one Cell provides that spine. Nothing lives in two places. A Cell that needs identity behaviour changes the identity spine's own code; it does not grow a local copy of login logic because that felt faster in the moment.
The second piece was separating two graphs that kept getting drawn as one diagram and confusing everyone reading it. A dependency graph — who needs whom to exist at all — is acyclic and points strictly downward: a product may depend on a service, a service on a plane, a plane on the substrate, never the reverse. An information-flow graph — who tells whom what happened at runtime — is a completely different shape, with loops: telemetry flows upward from the substrate through every plane to an operator console, and policy flows back down. Drawing both on one whiteboard as if they were the same relationship was the source of a lot of accidental confusion about what could safely change without warning something else.
The third piece is the part that gives the model its name: every Cell, whatever its size, exposes the same contract card — what stratum it sits in, what it provides, what it consumes, how it is built and deployed, how it is observed. A single engine and the entire estate can be described with the same handful of fields, which means the same reasoning that works for reviewing one small service scales, unchanged, to reasoning about the whole system. That self-similarity is the actual point of calling it fractal, not a metaphor bolted on afterward.
The last piece is a duty, not a diagram: every change has to name, before it merges, every other Cell it affects, and inform each one in the same session — a pull request, an issue, a line in a changelog — rather than trusting that word will get around. Governance itself sits outside the strata entirely, as a loop rather than a layer: propose, build, preview, verify the claim against the actual code, gate the merge, deploy, observe what happens, and feed what was observed back into the next decision. None of this replaced anything that existed before; it gave a name and a shape to discipline that had mostly been informal, and made the informal parts precise enough to hold someone to.
← all logs