{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiez7kdmafmge4wuvaj5lssd76euqmqdecptafskbnzdqmruynizca",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3moocuqmpgjp2"
  },
  "path": "/t/software-architecture-is-fractal-read-only-if-youre-bored/1384155#post_6",
  "publishedAt": "2026-06-19T21:30:10.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "GitHub - TechSpokes/skill-postgres-introspection: AI Agent Skill for Postgres Database Introspection · GitHub",
    "Foundations for the Study of Software Architecture",
    "decomposing systems into modules",
    "Perspectives on an Emerging Discipline",
    "ISO/IEC/IEEE 42010",
    "Software Architecture in Practice",
    "Documenting Software Architectures: Views and Beyond",
    "C4 model",
    "Structurizr DSL",
    "arc42",
    "UML Component",
    "1995",
    "2001",
    "Domain-Driven Design reference",
    "Conway’s law",
    "Team Topologies",
    "cooperative principle and maxims",
    "design rationale",
    "tacit knowledge",
    "phronesis",
    "Architecture Decision Records",
    "ADR community",
    "MADR",
    "Design by Contract",
    "assume-guarantee reasoning",
    "OpenAPI",
    "AsyncAPI",
    "Pact",
    "JSON Schema",
    "CUE",
    "SHACL",
    "RDF",
    "OWL",
    "fractals",
    "A Pattern Language",
    "Keenan Crane has a clear walkthrough",
    "Finsler geometry",
    "anisotropic",
    "ArchUnit",
    "NetArchTest",
    "jQAssistant",
    "Lattix",
    "Code Property Graph",
    "Joern",
    "Open Policy Agent",
    "Rego",
    "architecture fitness functions",
    "Building Evolutionary Architectures",
    "OpenTelemetry semantic conventions",
    "service level objectives",
    "Architectural Knowledge Management vision paper",
    "Policy as Code, Policy as Type",
    "ARPaCCino",
    "Do Large Language Models Respect Contracts?"
  ],
  "textContent": "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.\n\nThe lens is mine, the parts are not.\n\nThe 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\n\nWhat architecture actually is.\n\nThe 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).\n\nArchitecture is a language problem.\n\nEric 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.\n\nThe why nobody writes down.\n\nThat 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.\n\nUnits already declare their edges.\n\nNot 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.\n\nThe fractal, and the rabbit hole I cannot unsee.\n\n“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.\n\nThe tools that already check this, scattered across fields.\n\nStructural 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.\n\nEvidence at runtime, and goals with numbers.\n\nWho 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.\n\nAnd the newest work, where models meet architecture.\n\nPeople 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?\n\nThe post just stacks it in one pile and points at the shape it keeps making.",
  "title": "Software Architecture Is Fractal (read only if you're bored)"
}