FPF Reference

    FPF.Preface:13 - Architecture As Structure Of Holons

    Preface node heading:fpf-preface-13-architecture-as-structure-of-holons:1101

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    FPF treats architecture as structure of a holon in a context, not as a diagram, document, approval, promise, or implementation plan.

    This makes architecture broad. There can be architecture of a physical system, software system, organization, work system, body of knowledge, publication system, research program, AI-agent arrangement, or FPF itself. Wherever holons have structure, architecture can be discussed.

    Architecture descriptions, structural views, viewpoints, diagrams, models, and publication forms are descriptions or publications about architecture. They are valuable, but they do not replace the architecture itself.

    The architecture pattern descriptions make this distinction usable without creating a second ontology. The defining or constraining ClaimGraph sources are located at C.30 for architecture as an EntityOfConcern, A.22 for selected structure, C.30.ASV for architecture structural-view assertions, C.30.AD for architecture-description assertions, and A.6.M for module-interface relation repair. C.31 and related architecture pattern descriptions locate exact rule content for modularity, reusable structure, scale, interlevel tension, and architecture-changing assertions. Architecture, selected structure, each description episteme, each view, each publication, and each change remain separate subjects.

    This matters because architecture work is not only "draw the diagram". It is also "which structure matters", "what characteristic changes", "what tradeoff is visible", "what description is needed", "what interface claim is being made", "what evidence would make this architecture decision responsible", and "which move changes the architecture rather than merely changing a document about it".

    Assess how hard a holon is to understand, change, control, reuse or improve under the declared architectural characteristics and concerns. Keep the structural dependencies that contribute to this difficulty visible in descriptions, including simplified diagrams.

    Extractable structural information is a reader-relative characteristic of a publication, assessed for the intended reader's preparation and available budget. It applies, for example, to a pattern's text, an explanation in a guide or an architecture description. Epiplexity formalizes structural information extractable from data by computationally bounded observers (Finzi et al., §3); C.29:4.2c governs the use of that mathematical lens. A.6.3.NAR supplies the source-to-narrative relation for narrative publications. What counts as an improvement depends on the named object and intended use.

    Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)