FPF Reference

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

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

    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-existence architecture-description use, or a post-PFAD account of authoring dependencies. Each proposal or dependency description below is an ordinary local label for one C.2.1 episteme identified by its exact ClaimGraph, EntityOfConcern, and effective ReferenceScheme. ClaimScope, empirical grounding, optional interpretation-changing model-use structure, Work or WorkPlan, edition, package architecture, publication occurrence/form, presentation carrier, and access use remain separate.
    • Template A. E.4.DPF Solution -> FrameworkOrganizationDesignProposal. Select before PFAD when one current C.2.1 proposal episteme makes candidate organization claims reviewable. Its EntityOfConcern is the separate present IntendedFrameworkResultDescription episteme; that description has the current A.15.2 U.WorkPlan as its own EntityOfConcern. Each episteme keeps its own ClaimGraph and effective ReferenceScheme. Any ClaimScope, C.2.1 empirical-grounding relation to an exact A.1-admitted holon, or selected BoundedModelUseStructure is a neighboring qualification, not a shared identity slot. The proposal 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, recommendation-as-duty, or prohibition exits to A.2.8, while an exact permission claim exits to A.2.8.PER; 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 -> exact framework-architecture decision relation. Select when framework family, Core dependency boundary, content boundary, pattern relation structure, publication architecture, or access architecture is the current decision question. The decision relation and decision episteme exist independently of any ADR-like publication, package path, or carrier.
    • Template C. C.30.AD Solution -> ArchitectureDescriptionUseCard@Project. This is C.30.AD's retrieval-only foreign name. Select it only after the framework entity, exact C.30 architecture relation, and selected architecture-relevant structures exist, and when admissible use of the corresponding architecture description is current. The suffix supplies no project identity or locality; an actual project requires the exact A.15.6 composite project U.Work and a separately obtaining architecture-description project-use relation under its direct owner.
    • Template D. E.4.DPF Solution -> FrameworkAuthoringDependencyDescription. 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 has the current DPF-authoring U.WorkPlan as EntityOfConcern, one dependency-claim graph, and one effective ReferenceScheme. Its ClaimScope, any empirical-grounding relation, optional interpretation-changing model-use structure, dated Work, edition, package, publication, and carrier relations remain separate. It 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 retrieval card while post-existence 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.
    • Result test. The potential result is exactly the organization-design proposal, PFAD decision relation, architecture-description use card, or authoring-dependency description named by the selected template and identified under its direct Solution. Name the exact intended-framework U.WorkPlan, architecture decision, description use, or next authoring U.Work it would answer and the exact relation, binding, or supported claim that makes it this DPF-authoring use's result. A return to PFAD, publication, or further authoring is a continuation only when current; otherwise stop with the missing proposal basis, architecture decision, dependency, governor, or information.
    • Public coarsening. "DPF authoring" is only a thin reader cue. Under the stated condition, restore it to the current C.2.1 organization-design proposal, the exact E.4.PFAD framework-architecture decision relation, C.30.AD's retrieval-only ArchitectureDescriptionUseCard@Project, or the current C.2.1 authoring-dependency description. The cue supplies no context object, architecture relation, project locality, package membership, publication, or carrier semantics by itself.

    Last Updated: 2026-08-03 — upstream FPF commit 9dd92159 (github.com/ailev/FPF)