FPF Reference

    Architecture As Structure Of Holons

    Preface node heading:architecture-as-structure-of-holons:1063

    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".

    Epiplexity is one important architecture characteristic. It names the structural entanglement that makes a holon hard to understand, change, control, reuse, or improve. A low-epiplexity design is not merely simpler in ordinary speech. It is structurally easier to reason about under declared characteristics and concerns.

    Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)