FPF Reference

    DPF-AUTHORING - Build a reusable FPF-grounded domain framework

    Preface node heading:dpf-authoring-build-a-reusable-fpf-grounded-domain-framework:599

    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

    • Situation and question. A domain or local practice needs a reusable FPF-grounded framework edition rather than isolated advice. Ask whether the useful first result is a present organization-design proposal about an intended future framework, a settled framework-architecture decision, a post-claim architecture-description use, or a post-PFAD account of authoring dependencies.
    • Template A. E.4.DPF Solution -> FrameworkOrganizationDesignProposal@Context. Select before PFAD when one current C.2.1 proposal episteme makes candidate organization claims reviewable. Its EntityOfConcern is a present intended-framework-result description whose EntityOfConcern is an A.15.2 U.WorkPlan; proposal and description share the description's exact A.1-admitted grounding holon. Its one ClaimGraph carries typed candidate claim nodes and proposed subject relation signatures. A relation-family coverage constraint node carries covered family ref-kind pairs, admitted use, and coverage criterion; a WorkPlan acceptance target remains separate basis. A materialized PUA expectation expects this proposal, not the later framework edition. Claim status carries proposedness; accountable obligation exits to A.2.8; a separate return points to E.4.PFAD when framework-architecture settlement is current. Optional proposal meta-structure never substitutes for proposed subject organization.
    • Template B. E.4.PFAD Solution -> PrincipleFrameworkArchitectureDecision@Context. Select when framework family, Core dependency boundary, content boundary, pattern relation structure, publication architecture, or access architecture is the current decision question. The filled decision relation exists before any ADR-like publication of it.
    • Template C. C.30.AD Solution -> ArchitectureDescriptionUseCard@Project. Select only after the framework entity, ArchitectureOf@Context, and selected architecture-relevant structures exist, and when admissible use of the corresponding architecture description is current.
    • Template D. E.4.DPF Solution -> FrameworkAuthoringDependencyDescription@Context. Select only when PFAD exists and the immediate need is a minimal account of dependency availability and relevance for the next authoring use. This C.2.1 episteme concerns the current DPF-authoring U.WorkPlan, has one exact grounding holon, ClaimGraph, and ReferenceScheme, and contains at least the Core-edition, source-basis, and PFAD dependency positions. Core edition and PFAD are available with exact value-kind refs. Another missing dependency has an acquisition-condition description and no value ref; an available dependency has exact value and kind refs and no acquisition condition. Relevance remains independent in both branches. Future products need not exist; a missing PFAD returns to Template B.
    • Boundaries. Stop at the proposal while its candidate organization ClaimGraph is the current result, at PFAD while framework-architecture settlement is current, at the C.30.AD use card while post-claim description use is current, or at the dependency description when it makes the next authoring work recoverable. Return when intended result kind, current intended-result description, proposal basis, design question, candidate relation signature, constraint, invariant, dependency direction, alternative, unresolved position, Core edition, source basis, architecture decision, publication or access use, quality result, or currentness changes. Neither a topic list nor an organized proposal document without proposed subject relations is a proposal result.
    • Public coarsening. "DPF authoring" restores to FrameworkOrganizationDesignProposal@Context, PrincipleFrameworkArchitectureDecision@Context, ArchitectureDescriptionUseCard@Project, or FrameworkAuthoringDependencyDescription@Context under the stated condition.

    Last Updated: 2026-07-12 — upstream FPF commit 44dd8818 (github.com/ailev/FPF)