FPF Reference

    Big FPF Storylines

    Preface node heading:big-fpf-storylines:963

    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

    Several commitments make FPF more than a collection of patterns.

    1. Holons give one root for systems, bodies of knowledge, organizations, publications, methods, and other entities that can be treated as wholes and parts.
    2. The project thing under concern and its description are kept distinct so descriptions, views, diagrams, publications, and carriers do not replace what they describe.
    3. Context keeps meaning local, while bridges and term sheets let meanings travel without collapse.
    4. Role, method, plan, performed work, evidence, decision, and gate are different kinds of project objects.
    5. Architecture is structure of holons, and architecture descriptions are descriptions of that structure.
    6. Evidence and assurance are first-class, so trust is not reduced to confidence prose.
    7. Comparison and improvement require declared characteristics, scales, candidate sets, and current comparator fields.
    8. Creativity is governed search over candidate possibilities, not an uninspectable burst of inspiration.
    9. State of the art is a refreshable publication object, not a frozen leaderboard.
    10. Semantic precision starts from ontology and, when useful, from mathematical modeling that preserves declared structure, not from synonym replacement.
    11. Pattern publication is itself part of the thinking architecture: patterns, DRRs, checks, and improvement loops keep FPF evolvable.
    12. Didactic primacy keeps the whole structure usable by working readers rather than only by authors of the specification.

    These storylines are connected. Architecture needs characteristics. Characteristics need comparison. Comparison needs evidence. Evidence needs publication and source-use discipline. Language repair needs ontology. Ontology often benefits from a mathematical lens. Improvement needs state-of-the-art comparison. FPF's value comes from the composition.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)