Software Architecture Is Fractal (read only if you're bored)

By the way, if you are wondering what any of this is actually based on, here is the whole pile. I did not invent most of it. I noticed it was all quietly describing the same shape and put it in one place. The lens is mine, the parts are not. The framing comes from a few things I have been writing up: the Three-Body Problem of cross-intelligence communication (humans, language models, and deterministic tools, and everything lost translating between them), a Universal Problem-Solving Framework (the recursive idea that a problem and a task are the same object at different sizes), and what I call Form Architecture (message structure as an engineering variable, not decoration). The one slice that is already public and actually running is a small skill that makes a Postgres database describe itself and keep its reasons next to the data instead of in a doc that rots: GitHub - TechSpokes/skill-postgres-introspection: AI Agent Skill for Postgres Database Introspection · GitHub What architecture actually is. The old guard already said most of it. Perry and Wolf’s Foundations for the Study of Software Architecture, Parnas on decomposing systems into modules, Shaw and Garlan’s Perspectives on an Emerging Discipline, and ISO/IEC/IEEE 42010 for the formal version of “architecture must be described, not felt.” The SEI books carry it into practice: Software Architecture in Practice and Documenting Software Architectures: Views and Beyond. For the zoom-levels idea there is Simon Brown’s C4 model and its Structurizr DSL, arc42, and even the humble UML Component. The gap between intended and actual structure has had a name for decades, the reflexion model (1995, 2001). Architecture is a language problem. Eric Evans’ Domain-Driven Design reference is the whole “everyone must mean the same thing by the same word” argument. Conway’s law is the other half, a system ends up shaped like the communication of the people who built it, and Team Topologies is the modern operational version of that. For the linguistics proper, Paul Grice’s cooperative principle and maxims read like a prompting guide written fifty years early. The why nobody writes down. That the reasons live in someone’s head until they feel obvious and quietly vanish is design rationale, Michael Polanyi’s tacit knowledge (“we know more than we can tell”), and Aristotle’s phronesis, the practical wisdom that refuses to become a rulebook. The bandage is to write the reason next to the decision: Architecture Decision Records, the ADR community, and MADR. Units already declare their edges. Not new either. Design by Contract and assume-guarantee reasoning are the formal versions, and the industry already writes interface contracts every day: OpenAPI, AsyncAPI, Pact for contract testing, and JSON Schema. To write units and constraints in something plain that a machine can still check, there is CUE, and for meaning that survives travel, the semantic-web stack solved a lot of this already: SHACL for shape constraints, RDF, and OWL. The fractal, and the rabbit hole I cannot unsee. “The same shape at every scale” is just self-similarity, which is Mandelbrot’s fractals and, in software, Christopher Alexander’s A Pattern Language. The prettiest version uses quaternions: the usual fractal run with four-dimensional numbers instead of two, so the shape lives in 4D and you slice it down to 3D to see it (Keenan Crane has a clear walkthrough). Now the hunch, not a theorem. Finsler geometry is distance that depends on direction, and the embedding spaces inside these models are anisotropic, where distance also depends on direction. Slice one of those down to 3D and it looks a lot like the fractal on the table. I have no proof that architecture, meaning, and embeddings share one geometry. I just keep seeing the same picture, which is half of why I wrote the post. The tools that already check this, scattered across fields. Structural conformance: ArchUnit for Java and NetArchTest for .NET. Code as a graph you can query: jQAssistant, Lattix, and the Code Property Graph behind Joern. General policy over any structured input: Open Policy Agent and Rego. And the “make architecture a test that runs forever” idea: architecture fitness functions and Building Evolutionary Architectures. Evidence at runtime, and goals with numbers. Who actually talks to whom comes from OpenTelemetry semantic conventions, and “maintainable” only becomes checkable once it is a number, which is what Google SRE’s service level objectives are for. And the newest work, where models meet architecture. People are already pushing on this exact seam: an Architectural Knowledge Management vision paper, Policy as Code, Policy as Type, ARPaCCino for agentic policy-as-code compliance, and Do Large Language Models Respect Contracts? The post just stacks it in one pile and points at the shape it keeps making.