#Domain Principle Framework Authoring and Publication-or-Access Carrier Assembly

E.4.DPF · Stable · Architectural (A) · Normative unless marked informative. · Part E - The FPF Constitution and Authoring Guides

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

Use this pattern when a group needs to create a domain principle framework or local practice framework grounded in FPF: for example a hydroponic-cucumber framework, a neural-network architecture framework, or a Codex-process framework.

#Relations

#Content

#Problem frame

Use this pattern when a group needs to create a domain principle framework or local practice framework grounded in FPF: for example a hydroponic-cucumber framework, a neural-network architecture framework, or a Codex-process framework.

This pattern describes the reusable way of authoring or revising an FPF-grounded framework, not the files that happen to carry it. Start by writing one paragraph that names the intended reader, first use, ordinary non-use boundary, and the domain or local situation. That paragraph is the first useful move: it is enough to enter the first-hour route before the framework architecture, durable names, or publication package are settled.

Use this pattern when the work creates or revises the framework itself. Use E.11 or E.17 when an existing framework remains unchanged and the work only changes how readers or agents find or access it.

#Problem

Domain and local framework authors often have strong source material and urgent local needs, but they can lose FPF discipline in three ways. They copy FPF terms without settling the domain ontology. They publish a framework carrier before deciding the framework architecture. Or they produce a useful checklist that is local process guidance but not yet an FPF-grounded pattern framework.

A working framework needs more than a good table of contents. It needs source-grounded pattern selection, architecture decisions, relation records, edition dependencies, names, worked cases, quality evaluation, and refresh conditions.

A DPF is not a domain ontology, glossary, literature survey, or guide to talking about a topic. It exists so an intended practitioner or assisting agent can enter typical problem situations in the domain, avoid known failure modes, and apply source-grounded SoTA solution moves with visible boundaries and refresh conditions. Those failure modes include beginner mistakes and experienced-practitioner failures caused by stale, local-only, or non-SoTA practice. Ontology and vocabulary matter only insofar as they make those problem-solving moves safer and more reusable.

#Forces

#Solution

Start here: write the one-paragraph use-frame note, then take the nine-step route below. The route lets a first-time framework author obtain one inspectable seed package and choose the exact first-result branch without first decoding the full precision model. Stop at the first-hour boundary unless the next receiving use already requires the complete route or stronger assurance.

First-hour route for a first framework:

1. Write a one-paragraph domain or local use-frame note: intended reader, first use, non-use boundary, effective ReferenceScheme, ClaimScope, and qualification window; add a selected BoundedModelUseStructure only if its organization changes interpretation for that use.
2. Create a source-pack stub: source traditions to inspect, rival traditions to avoid losing, first examples, and claim status.
3. Decide which first result is current. Before PFAD, create the C.2.1 proposal episteme locally called FrameworkOrganizationDesignProposal when review of candidate subject organization is current. Open E.4.PFAD when settlement of framework architecture is the current decision. Use C.30.AD only after the framework and its architecture exist; treat ArchitectureDescriptionUseCard@Project as its retrieval-only name and recover an actual composite project U.Work plus the separately obtaining project-use relation when project locality is claimed. Use the C.2.1 episteme locally called FrameworkAuthoringDependencyDescription only after PFAD.
4. For a pre-PFAD proposal, make the intended result present through one C.2.1 IntendedFrameworkResultDescription whose EntityOfConcern is the current A.15.2 U.WorkPlan. Keep its exact ClaimGraph, effective ReferenceScheme, ClaimScope, and any separately obtaining empirical-grounding relation distinct. Put candidate organization claims in the proposal's one ClaimGraph.
5. Mark public names provisional: use Domain Principle Framework or Local Practice Framework in prose, and send durable names or abbreviations to F.18.
6. Draft one to three first pattern candidates through E.8, each with a recognizable problem frame, known failure mode or local anti-pattern, positive SoTA-informed solution move, worked slice, and boundary. When a stable Solution benefits from a short repeatable Plain formulation, add a local mantra that preserves the Solution's operative distinctions and nearest stop or return condition. A local mantra is optional and pattern-specific; repetition does not make it a new Method, work order, U-kind, CGUS, or demonstrative unfolding slice. In the first hour these are pattern seeds unless they already pass the declared E.21 pattern-quality use.
7. Add relation and edition rows for those candidates: source reuse, specialization, publication, dependency, compatibility, or currentness return as needed.
8. Pick the publication or access carrier: readme, preface, table of contents, card set, all-in-one local carrier, split document set, skill pack, MCP-backed access service, or another access face.
9. Name the first quality and currentness route: what will be evaluated, what can improve next, and what source, Core edition, or local-use change reopens the framework.

Stop the first hour when those outputs exist, even if every pattern body is still rough. A rough framework with a declared use frame, source basis, current first-result relation, provisional names, first pattern candidates, relation rows, publication or access carrier, quality route, and currentness return is inspectable. These are admitted outputs only through their direct owners and named receiving uses; list order does not produce them. A long all-in-one carrier without those outputs is not yet an FPF-grounded framework. Do not promote this rough output to a reliance-bearing DPF publication carrier until the DRR or decision carrier is checked for the intended authoring use, the pattern bodies are hardened as normal FPF patterns, and the package is evaluated through E.4.DPF.DA.

Precision and object boundary after the first route. The first-hour route is Plain application guidance for one exact run-independent framework-authoring U.Method; this E.4.DPF pattern is its action-guiding U.MethodDescription under E.8 and A.3.2. The Method, this description episteme, any U.WorkPlan, every dated authoring U.Work, and every result remain different objects. An admitted authoring system performs dated Work under an obtaining U.RoleAssignment; the Work enacts the Method and may use this description through exact A.6.1 application and bindings. A numbered list, imperative sentence, document order, file layout, or coordination table neither performs Work nor establishes a result.

The first useful output is whichever exact current result and receiving use closes the immediate authoring question: a pre-PFAD organization-design proposal, a settled PFAD architecture decision, a post-existence architecture-description use, or a post-PFAD dependency description. Each output exists only when its direct owner admits it and an exact receiving use is named: G.2 owns source-use results; E.4.DPF owns the pre-PFAD proposal and post-PFAD dependency description; E.4.PFAD owns the architecture decision; E.8 owns pattern-authoring guidance; E.4.PFR owns relation and edition records; E.24.PUB, E.11, and E.17 own publication or access uses; E.4.DPF.DA and E.21 own evaluation results; E.23 owns repeated improvement; and G.11 owns currentness and refresh. Step completion, co-location in a package, or an arrow between labels supplies none of those result relations.

If one receiving use genuinely needs reusable conditional unfolding, select one exact A.22.CGUS ConstraintGovernedUnfoldingStructure separately from this MethodDescription. Recover its A.22 identity, independently governed constituents and obtaining relations, applied constraints, more than one admissible continuation, and explicit stops or returns; keep any demonstrative walkthrough as a separate C.2.1 episteme. Otherwise keep the route Plain. Neither the first-hour list nor the complete route is a CGUS merely because it contains branches or imperatives.

When dated authoring Work first constitutes a framework episteme or a revised framework episteme, recover that exact local inception claim through A.15.PROD; do not infer production from step order. C.2.1 identifies each authored framework episteme by its exact ClaimGraph, EntityOfConcern, and effective U.ReferenceScheme. An obtaining EpistemeEditionRelation, the authoring change or inception claim, the package architecture, and any EpistemePublicationRelation remain separately revisable. Publication occurrence, publication form, and presentation carrier establish availability only under E.24.PUB; they do not establish framework truth, edition continuity, or package membership.

The complete authoring account keeps the domain or local use frame, source basis, selected architecture, names, pattern drafts, relation and edition records, publication or access, quality, improvement, and currentness returns recoverable without turning their order into another object.

Default artifact contract for a request such as "make a DPF about this topic" separates claim-bearing epistemes, publication forms, and carriers. In a campaign or repository setting, create a developer decision carrier such as SUBSTANTIVE-DRR.md or DPF-DRR.md governed by E.9 and checked by E.9.DA; it carries the source basis, selected architecture, PFAD decision, candidate pattern split, relation plan, quality plan, and rejected alternatives, while publishing or bearing the decision episteme rather than becoming that decision by file form. Create a user-facing framework publication or access carrier named by the individual framework, such as <DomainOrPractice>-PRINCIPLES-FRAMEWORK.md, <PublicFrameworkName>.md, a split readme, pattern, and appendix set, a skill pack, or an MCP-backed access service; it is the route through which readers or agents use the selected framework edition. Optional source-pack, E.4.PFR, quality-run, package-evaluation, skill-manifest, or access-service files may be separate when they need independent maintenance. C.2.1 framework-episteme identity, EpistemeEditionRelation, package architecture, E.24.PUB publication occurrence/form/carrier, and access use remain distinct; process state remains outside the user carrier.

Plain vocabulary for adoption:

Old intake labels such as SPF, TPF, or broad xPF remain source aliases until F.18 settles a durable public name and any admissible short form. For the current FPF term set, F.18 selects Tech name FoundationalPrinciplePatternSet with Plain name "foundational principle pattern set"; ZPF remains only its mnemonic alias, not a public "zero principles" framework name. If the alias suggests a different framework identity, return to the F.18 naming settlement and use the full public name.

Keep the authoring apparatus proportional to the next receiving use. A first exploration may stop with the nine seed outputs and no separate publication package. A compact reliance-bearing framework may keep its readme, preface, pattern bodies, relation rows, source-use account, and quality route in one carrier when the same readers and stewards maintain them together. Split source packs, decision records, relation records, pattern files, quality results, skills, or access services only when independent editioning, confidentiality, transfer, automation, delayed feedback, expensive reversal, or another named reliance makes their identity separately useful. The pre-PFAD proposal exists only while candidate subject organization is the current result; the post-PFAD dependency description exists only when dependency availability and next-use relevance must be recovered. More files or records do not make the framework more mature.

Prompt-shaped starter for SoTA harvesting and first candidate generation:

Help draft a first FPF-grounded principle-framework candidate.

Domain or local situation and semantic boundary: effective ReferenceScheme, ClaimScope, qualification window, and optional selected BoundedModelUseStructure only when interpretation depends on it:
Intended reader and first use:
Non-use boundary:
Source traditions to inspect:
Rival traditions or schools not to lose:
Local examples or internal sources:
Adopted source payload to carry into pattern solutions:
Rejected source payload and why rejected:
Recurring domain or local problem situations and forces:
Reusable solution moves and consequences:
Candidate first patterns, each with problem frame, positive solution, worked slice, and local anti-pattern:
Candidate relation functions among the patterns:
Current first result and selection condition: pre-PFAD proposal | settled PFAD architecture decision | post-existence architecture-description use | post-PFAD dependency description
Dependency on FPF Core or a domain framework edition:
Publication or access carrier for first use:
Quality route: which first drafts should be evaluated and improved:
Refresh triggers: source change, Core edition change, local-use telemetry, or policy change:

Return the result with the exact current first-result relation and only the adjacent source, naming, pattern-draft, relation, publication or access, quality, and currentness notes that its receiving use needs. If the requester wants a ready DPF rather than a seed, keep the developer DRR or decision carrier separate from the user DPF publication or access carrier, then name which `E.21`, `E.4.DPF.DA`, and currentness checks remain before reliance.
Do not present generated text as authoritative. Before reliance, name the unresolved claims and their returns to `G.2`, `C.35`, `E.4.PFAD`, `E.4.PFR`, `F.18`, `E.21`, and `G.11`.

1. Domain or local use-frame declaration. State the intended reader, first use, non-use boundary, effective ReferenceScheme, ClaimScope, and qualification window. Select a BoundedModelUseStructure only when its exact organization changes interpretation for this receiving use; the word context and a package boundary establish none of these.
2. Source pack. Use [G.2](/generated/patterns/G.2) to gather SoTA traditions, claim sheets, examples, source-use decisions, rejected alternatives, and source-currentness notes.
3. Organization proposal or architecture decision. Before PFAD, use E.4.DPF to create the current C.2.1 organization-design proposal described in 4.2-4.4. When framework-architecture settlement is current, use [E.9](/generated/patterns/E.9) and [E.4.PFAD](/generated/patterns/E.4.PFAD) to decide purpose, framework family, domain or local problem-and-solution architecture, pattern split, relation structure, publication and access architecture, dependency boundary, and source-return conditions. Keep the decision relation, decision episteme, package architecture, relation records, edition dependencies, and any ADR-like publication distinct. Do not use a dependency description to postpone PFAD.
4. Name preparation. Use [E.10](/generated/patterns/E.10) for kind discipline and [F.18](/generated/patterns/F.18) for durable names before public pattern heads or abbreviations are stabilized.
5. Carrier admission. Use [C.33](/generated/patterns/C.33), [C.34](/generated/patterns/C.34), or [C.35](/generated/patterns/C.35) before relying on all-in-one carriers, tables of contents, relation graphs, source summaries, search outputs, transformed views, or generated candidates as architecture evidence.
6. Pattern drafting. Draft patterns with [E.8](/generated/patterns/E.8): recognition text, positive solution, worked cases, boundary, local anti-patterns, SoTA-Echoing, conformance checks, and relations. In a DPF, those pattern bodies render selected domain or local problem-situation architecture and solution-move architecture. [E.8](/generated/patterns/E.8) means a normal action-guiding MethodDescription, not only a section skeleton. When repeated first use benefits from an attentional aid, write a Plain local mantra by compressing that pattern's Solution without dropping the distinction that makes the move work or the stop, return, or redirect condition. Keep an established local name such as mnemonic, watchword, or heuristic when it explains the aid better. Use [A.22.CGUS](/generated/patterns/A.22.CGUS) only when an independently selected ConstraintGovernedUnfoldingStructure has exact constituents, obtaining relations, constraints, admissible continuations, and stops; keep its demonstration separate. A thin skeleton, prompt seed, compressed design note, or memorable slogan detached from the Solution remains a pattern seed until [E.21](/generated/patterns/E.21) says the pattern is adequate for the declared DPF use.
7. Relation and edition discipline. Use [E.4.PFR](/generated/patterns/E.4.PFR) for relation functions, dependency direction, compatibility boundary, deprecation, supersession, and edition effects.
8. Quality cycle. Use [E.22](/generated/patterns/E.22) to frame the evaluation purpose, quality floor, trade-off question, and expected improvement proposal when that frame is not already scoped. Use [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) to evaluate the package as a DPF or local-framework package, [E.21](/generated/patterns/E.21) to evaluate individual pattern quality, [E.23](/generated/patterns/E.23) for repeated improvement, and [E.19](/generated/patterns/E.19) only when admission or profile gating is actually being claimed. If an evaluation result needs a carrier, publish or refresh that carrier through the pattern governing its publication or currentness relation rather than through [E.22](/generated/patterns/E.22).
9. Admission review. Use [E.19](/generated/patterns/E.19) when the local process asks whether a pattern or framework slice is ready for admission.
10. Framework publication-or-access carrier assembly. Expose the selected framework episteme edition through exact publication or access relations: an all-in-one local carrier, split readme/preface/pattern files, table of contents, cards, skill pack, MCP-backed access service, retrieval route, or another first-use form. Under E.24.PUB keep publication occurrence, selected episteme edition, audience declaration, bounded-use declaration, publication form, and presentation carrier distinct. Do not infer framework identity, package membership, truth, Work authority, or landing from carrier assembly, and do not land domain or local frameworks into FPF-Spec.md by default.
11. Currentness route. Use [G.11](/generated/patterns/G.11) for refresh plans, edition pins, source decay, deprecation, and supersession conditions.

Localize each repair before returning to wider framework architecture. A changed source payload first returns to its [G.2](/generated/patterns/G.2) source-use decision and then only to patterns, examples, or relations that relied on that payload. A changed Core or depended-on framework edition first updates the affected [E.4.PFR](/generated/patterns/E.4.PFR) dependency, compatibility, and migration relations. Repeated misuse of one pattern first returns to that pattern's [E.21](/generated/patterns/E.21) result and its [E.23](/generated/patterns/E.23) improvement loop. A failed publication or access route first returns to [E.11](/generated/patterns/E.11), [E.17](/generated/patterns/E.17), or the carrier relation that exposed it. A local mantra that no longer preserves its pattern's Solution first returns to that pattern body; [A.22.CGUS](/generated/patterns/A.22.CGUS) becomes current only if the repaired aid must present a wider conditional unfolding. Return to [E.4.PFAD](/generated/patterns/E.4.PFAD) only when the evidence changes selected framework-family, pattern-split, relation-structure, publication or access architecture, or dependency-boundary decisions. Use [G.11](/generated/patterns/G.11) when edition currentness, source decay, telemetry, deprecation, or supersession must be orchestrated across those local repairs.

For an all-in-one DPF publication carrier, assemble the content in a reproducible order. This order is a publication shape, not a new framework kind:

1. Public framework title and package edition ref: use a domain- or practice-specific framework name such as <DomainOrPractice> Principles Framework; Principles Framework alone is only the head or kind phrase, not an individual framework name. Do not put local monolith, draft, process status, or file-layout slang in the public title.
2. Dependency declaration: FPF Core edition, depended-on DPF or local-framework editions, and blocked reverse dependency.
3. Table of contents: pattern bodies first as the main language of use; support maps and relation records remain reachable without becoming a universal first inspection sequence.
4. Readme or first practical entries: intended reader, first use, non-use boundary, first outputs, and a short statement of which selected domain or local structures this carrier exposes for that reader.
5. Preface or framework context: cross-cutting ideas that make the pattern set cohere, plus the selected structure families the carrier foregrounds, deliberately coarsens, defers, or sends back to sources and pattern bodies.
6. Package carrier structure-account: intended reader and use, selected source-structure denominator, recurring problem-situation structures, reusable solution-move structures, captured structure, deliberately coarsened, abstracted, omitted, or lost structure, source-return condition, and quality or epiplexity route. This may be a short subsection in the readme or preface when the carrier is compact.
7. Package boundary and governing-pattern routing: Core governing patterns reused, local terms bounded, and source, evidence, assurance, publication, and refresh exits named.
8. Pattern index: pattern ids, titles, first use, and any local prefix discipline.
9. Pattern bodies: each drafted through [E.8](/generated/patterns/E.8), with recognition text, positive solution, worked cases, local anti-patterns, SoTA-Echoing, conformance checks, and relations, and each evaluated or explicitly marked as a seed under [E.21](/generated/patterns/E.21) before the package is claimed for public, teaching, enterprise, or reliance-bearing use.
10. Heterogeneous acceptance cases or transfer probes: examples that force the pattern set to work across unlike uses rather than only repeating the motivating case.
11. Support maps or appendices: architecture bridge, source-use map, precision map, package-name route, or other reference material placed after pattern bodies unless a short front-door trigger table is needed.
12. Source use and refresh map: source rows with adopted payload, rejected or bounded readings, return conditions to [G.2](/generated/patterns/G.2) for source use, and return conditions to [G.11](/generated/patterns/G.11) for source currentness or refresh orchestration.
13. Pattern-framework relation and edition records: [E.4.PFR](/generated/patterns/E.4.PFR) rows for dependency, specialization, publication, source reuse, evaluation, generated-carrier, teaching publication-carrier, ethics, deprecation, or supersession relations.
14. Refresh route: what returns to source, pattern quality, package adequacy, edition dependency, or publication carrier when source, Core edition, local use, telemetry, or evaluation changes. Every DPF publication or access carrier bears or serves a publication expression or access expression that makes selected domain or local structures available for a declared reader and use; the carrier is not itself the framework edition, the domain, or a narrative by type. In an all-in-one publication carrier, the readme and preface usually carry the first explanatory route, and sometimes a narrative rendering, through the domain. Their representation relation remains inspectable when they say what they are telling, for whom, which structures they foreground, which structures are deliberately coarsened, abstracted, omitted, or left to source return, and where a reader returns for fuller pattern, source, evidence, or relation detail. This is not only text-to-text summarization: the source-bearing side may be actual or possible holon structure, an architecture description, a view, a source pack, a model, a graph, or a pattern set. In architecture-mediated narrative-rendering use, read the return chain as narrative rendering carried by a publication or access carrier -> architecture description or view -> architecture as selected structures under its exact use frame -> wider source structures. When no narrative rendering is present, read the first step as framework publication or access carrier -> selected source structures. Each step has selected structure, captured structure, coarsening, abstraction, omission, loss, and return conditions. An architecture description is often already a coarsened representation of selected real, expected, candidate, or actual structures, so the DPF carrier keeps that second-step loss visible. This does not make every DPF a literary narrative or make every carrier a narrative; it makes the publication-expression or access-expression representation relation inspectable. When a sequential narrative rendering is load-bearing, use [A.6.3.NAR](/generated/patterns/A.6.3.NAR); when the publication expression deliberately keeps only a narrower-use coarsened rendering, use [A.6.3.CSC](/generated/patterns/A.6.3.CSC); for structure capture and loss, use [C.33](/generated/patterns/C.33); for same-enough or preservation claims, use [C.34](/generated/patterns/C.34); for practical-use publication, use [E.11](/generated/patterns/E.11) and [E.17](/generated/patterns/E.17); for package adequacy, use [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA).

Keep process state out of the carrier. DRR text, handoff notes, ledger rows, review status, helper state, admission blockers, and landing evidence may shape the package, but the publication carrier should contain only durable user-facing package content, source-use boundaries, relation records, quality routes, and refresh conditions. A short source-use or relation record may appear in the user carrier when it helps readers and maintainers use the DPF; a DRR argument, review transcript, or quality proof does not.

For skill packs and MCP-backed access, keep the same framework edition identity and relation records visible. A skill or endpoint may help a user find, select, retrieve, render, or apply DPF patterns, but it is an access carrier until another governing pattern makes a stronger claim. If the carrier generates candidate text, use [C.35](/generated/patterns/C.35); if it performs work or triggers tools, use [A.15](/generated/patterns/A.15) and the pattern governing the local tool or work relation; if it claims currentness, evidence, assurance, or decision authority, use [G.11](/generated/patterns/G.11), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [E.9](/generated/patterns/E.9), or the pattern governing that exact claim. Do not read a skill manifest, MCP tool name, endpoint schema, or protocol route as the DPF architecture.

Starter evaluation characteristics for a principle-framework improvement loop:

These are evaluation characteristics for selecting and framing improvement work. They are not measurement programs by themselves. If the pass needs a DPF package adequacy result, use [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA); if it needs individual pattern quality, use [E.21](/generated/patterns/E.21); if it needs DRR adequacy, FPF-level Pillar adequacy, measurement, evidence, or architecture-characteristic evaluation, use the pattern that owns that object, such as [E.9.DA](/generated/patterns/E.9.DA), [E.2.DA](/generated/patterns/E.2.DA), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), or the relevant architecture-characteristic pattern.

The MethodDescription and its result/use account are sufficient only when a reader can answer: which framework episteme edition is being authored; which dated Work, exact Method enactment, and result relation are current; what problem-and-solution architecture it renders; which sources and decisions shaped it; which patterns, relation records, and edition dependencies were selected; which publication occurrence, form, carrier, or access relation exposes it; how quality improves; and when it returns for refresh or repair.

#Select the current first result

DPF authoring has four possible first results under explicit conditions:

1. E.4.DPF Solution -> FrameworkOrganizationDesignProposal when PFAD is not yet settled and the immediate result is a current proposal episteme that makes candidate organization claims about an intended future framework result reviewable. The proposal exists now; the future framework need not.
2. E.4.PFAD Solution -> exact framework-architecture decision relation when framework family, Core dependency boundary, content boundary, pattern relation structure, or publication and access architecture is the current decision question. This is the first settled framework-architecture result; its decision episteme, decision relation, and any ADR-like publication remain distinct under their direct owners.
3. C.30.AD Solution -> ArchitectureDescriptionUseCard@Project only after the relevant framework entity, exact C.30 architecture relation, and selected architecture-relevant structures exist and the immediate question is how that architecture description may be used. ArchitectureDescriptionUseCard@Project is C.30.AD's retrieval-only foreign name: @Project supplies no project identity or locality. When an actual project matters, recover the exact composite project U.Work under A.15.6 and the separately obtaining architecture-description project-use relation under its direct owner.
4. E.4.DPF Solution -> FrameworkAuthoringDependencyDescription only when PFAD exists and the immediate question is which later authoring dependencies exist and which are relevant to the next authoring use.

The pre-PFAD result is one present proposal episteme, not a reference to the absent future framework and not an architecture description. It conforms to C.2.1 instead of defining a second local episteme architecture. The four results are alternatives selected by the current question; list order neither produces them nor makes them stages of one universal lifecycle.

#Make the intended result reviewable before PFAD

First make the design target present. IntendedFrameworkResultDescription is an ordinary local use name for one exact current C.2.1 U.Episteme, not a root kind or card kind. C.2.1 identifies it by:

<exact intended-result ClaimGraph,
 current DPF-authoring U.WorkPlan as EntityOfConcern,
 effective U.ReferenceScheme>

The current A.15.2 WorkPlan declares coordination claims for possible future DPF-authoring Work, the intended framework-result kind, and its acceptance target. It is present now; a dated authoring Work occurrence and the framework result may remain future. The intended-result ClaimGraph states the domain or local use frame, readers, first uses, purpose, declared relation-family coverage constraints, intended-result constraints, and acceptance conditions. The effective U.ReferenceScheme interprets those claims. One exact A.2.6 ClaimScope separately bounds which claims and uses are current; changing scope does not substitute for changing the C.2.1 identity triple.

Do not add a generic context, description-context, or grounding position. If interpretation for the receiving use genuinely depends on an independently selected BoundedModelUseStructure, cite that exact A.1.1/A.22 structure as an optional neighboring use qualification; it does not replace effective ReferenceScheme or ClaimScope and does not enter episteme identity. If empirical grounding is current, state a separate C.2.1 EpistemeEmpiricalGroundingRelation to one exact A.1-admitted holon and the covered claim subgraph. The grounding relation, its evidence, the WorkPlan, any dated authoring Work, an actual A.15.6 composite project Work, and the description episteme remain distinct. Plain project wording mints no U-kind.

Each declared relation-family coverage constraint is one FrameworkOrganizationCandidateClaimNode with claimNodeKind=constraint. Its coveredRelationFamilyRefKindPairs[1..*] identifies each covered relation-family value together with its exact kind; admittedFrameworkUseDescriptionRef names the use for which that coverage matters; and coverageCriterionDescriptionRef states how satisfaction of this coverage constraint is judged. A current A.15.2 WorkPlan acceptance target remains a different position: cite it through designBasisRefs[] or its direct acceptance-target relation. It neither replaces the coverage criterion nor shares one union field with it.

#Create one C.2.1 proposal episteme

The organization proposal uses the present intended-result description as its one EntityOfConcern:

FrameworkOrganizationDesignProposal:
  C2_1Identity:
    entityOfConcernRef: U.EpistemeRef
      = current IntendedFrameworkResultDescription episteme
    claimGraph: U.ClaimGraph
    effectiveReferenceScheme: U.ReferenceScheme
  claimScopeRef: ClaimScopeRef governed by A.2.6
  intendedReaderDescriptionRef: U.EpistemeRef
  intendedFirstUseDescriptionRef: U.EpistemeRef
  modelUseStructureRef?: U.StructureRef
    only when one selected BoundedModelUseStructure changes interpretation for this use
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
    only for separately obtaining C.2.1 empirical-grounding relations

FrameworkOrganizationDesignProposal is a local use label for that exact C.2.1 episteme, not a second U-kind. Its one EntityOfConcern, one constituting ClaimGraph, and one effective ReferenceScheme supply episteme identity. ClaimScope, reader and use descriptions, optional model-use structure, empirical-grounding relations, A.7 provenance, F.15 proposal-status assertions when current, publication, and edition continuity are neighboring claims or relations; none is another identity slot. A changed ClaimGraph, EntityOfConcern, or effective scheme identifies another episteme. A changed grounding relation alone changes that relation, not the proposal identity.

No generic grounding branch or unnamed Bridge is admitted. F.9 becomes current only for an exact cross-context local-sense translation with its own endpoints and predicate, not because two users, organizations, or empirical grounds differ. No CandidateFrameworkOrganizationClaim episteme kind is introduced. Candidate claims are typed nodes in the proposal's ClaimGraph, with logical, alternative, refinement, dependency, support, conflict, and answer-to-question edges as current.

Each candidate organization claim node makes the subject-level proposal recoverable:

FrameworkOrganizationCandidateClaimNode:
  claimNodeKey: semantic key unique within claimGraph
  claimNodeKind: FrameworkOrganizationClaimNodeKindValue
  claimStatus: FrameworkOrganizationClaimStatusValue
  intendedResultAspect: FrameworkOrganizationAspectValue
  describedPositionKinds[1..*]: U.Kind
  proposedSubjectRelationSignatures[0..*]: RelationSignature
  proposedConstraintDescriptionRefs[0..*]: U.EpistemeRef
  coveredRelationFamilyRefKindPairs[0..*]: FrameworkRelationFamilyRefKindPair; cardinality [1..*] for a relation-family coverage constraint node
  admittedFrameworkUseDescriptionRef?: U.EpistemeRef; exactly one for a relation-family coverage constraint node
  coverageCriterionDescriptionRef?: U.EpistemeRef; exactly one for a relation-family coverage constraint node
  proposedInvariantDescriptionRefs[0..*]: U.EpistemeRef
  proposedDependencyDirectionDescriptionRefs[0..*]: U.EpistemeRef
  alternativeGroupKey?: semantic key unique within claimGraph
  designBasisRefs[1..*]: U.EpistemeRef
  designQuestionRefs[1..*]: U.EpistemeRef
  pfadSettlementConditionRef?: U.EpistemeRef

FrameworkRelationFamilyRefKindPair:
  relationFamilyRef: U.EntityRef
  relationFamilyKindRef: U.KindRef

FrameworkOrganizationCandidateClaimNode is a local ClaimGraph node form, not a U-kind and not an episteme. FrameworkOrganizationClaimNodeKindValue is the local C.2.1-compatible enumeration definition | constraint | property | assumption. A node with claimNodeKind=constraint classifies a proposed constraint claim; its proposedConstraintDescriptionRefs[] identify the exact constraint descriptions that the node asserts, while a non-constraint node may cite those refs only when they qualify that definition, property, or assumption.

A relation-family coverage constraint node also has non-empty coveredRelationFamilyRefKindPairs[], one admittedFrameworkUseDescriptionRef, and one coverageCriterionDescriptionRef; other claim nodes leave all three coverage positions absent. Each pair identifies one relation-family value and its exact kind without a union field or an untyped companion list. A WorkPlan acceptance target, when current, is cited separately through designBasisRefs[] or its direct acceptance-target relation. Neither constraint position is deontic. If an obligation, recommendation-as-duty, or prohibition with an accountable subject and issuing or authority relation is current, use [A.2.8](/generated/patterns/A.2.8) -> U.Commitment; if a strong or weak permission, exercise, non-violation, or permission-conflict claim is current, use the exact [A.2.8.PER](/generated/patterns/A.2.8.PER) result with the participants, references, constructive ground, and qualifiers required by that selected object.

FrameworkOrganizationClaimStatusValue is the local enumeration candidateProposed | rejectedAlternative | unresolved. FrameworkOrganizationAspectValue is the local enumeration frameworkFamily | component | dependency | patternRelation | publication | access; a domain extension adds another value only together with its exact interpretation rule in the proposal's effective ReferenceScheme. Proposedness is claim modality: it says that a relation signature, position, constraint, invariant, or dependency direction is being proposed for the intended result. It asserts neither an actual relation occurrence nor an actual U.Structure, and it is not encoded as a pattern-use boundary condition.

The proposal's effective ReferenceScheme maps each organization-aspect value, described position kind, and proposed relation signature to claims about the intended result described by the EntityOfConcern; distinguishes ClaimGraph edges from the subject relations those claims propose; declares how basis and design-question refs qualify each claim; and states that claim status is modal rather than actual. Thus a claim node can propose that one pattern family depends on Core, that publication and access remain separate positions, or that one relation invariant is preserved, without pretending that the future framework or those relations already exist.

#Preserve result, PFAD, structure, and architecture boundaries

Keep the two result positions separate. If reliance-bearing E.11.PUA support materializes an exact expected-result support object for this E.4.DPF application, its expected result kind is the C.2.1 proposal episteme locally called FrameworkOrganizationDesignProposal. The intended later framework edition is described inside the separate IntendedFrameworkResultDescription and the proposal's ClaimGraph. One expectation support object never denotes both results, and neither object says the result was produced without the exact current work/result or inception claim.

PFAD return is also separate from claim modality. When a reliance-bearing use needs an addressable return condition, the exact E.11.PUA boundary support names E.4.PFAD as the receiving pattern and states which candidate claim, alternative, unresolved position, constraint, or dependency makes framework-architecture settlement current. That support is adjacent to use of the proposal; it is not a component that makes a claim proposed.

Subject organization is recovered from the candidate claim nodes, proposed subject relation signatures, described position kinds, constraints, invariants, dependency directions, alternatives, basis, questions, and PFAD settlement conditions. An A.22 U.Structure over the proposal ClaimGraph is optional and admissible only when the organization of the proposal episteme itself is a separate current EntityOfConcern. A selected BoundedModelUseStructure is a still different optional use qualification, admitted only when that exact organization changes interpretation for the receiving claim. Neither structure is the admission criterion for the proposal or a substitute for the organization being proposed. A topic list fails because it lacks candidate organization claims and proposed subject relation content, even if its headings or ClaimGraph are well organized.

Pre-realization C.33 notes compare proposal content only with a declared current comparator: design questions, present basis epistemes, candidate alternatives, a relation-family coverage constraint claim node for an admitted framework use, or an earlier existing framework edition. When coverage is the comparator, C.33 cites the exact candidate claim node and reads its covered family ref-kind pairs, admitted use, and coverage criterion. A separate WorkPlan acceptance target may appear in designBasisRefs[] or through its direct relation but never substitutes for the coverage criterion. The notes may report represented, omitted, hidden, or unresolved candidate organization content relative to that basis. They do not claim captured structure relative to an unknown future actual framework. Comparison with actual framework structures starts only after the framework entity and relevant structures exist.

No E.17.0 description/viewpoint device targets the absent future framework. Later E.4.PFAD, C.32, C.30, and C.30.AD results use their direct patterns and admission conditions; none retroactively retypes this proposal, its intended-result description, or its optional meta-structure as architecture or as an architecture description. C.30.AD's ArchitectureDescriptionUseCard@Project remains a retrieval cue; actual project locality additionally requires the exact composite project U.Work and its exact separately obtaining description-use relation.

#Describe post-PFAD authoring dependencies

The dependency description is minimal and status-bearing. It does not presume that later authoring products already exist:

FrameworkAuthoringDependencyDescription:
  C2_1Identity:
    entityOfConcernRef: U.EpistemeRef
      = current DPF-authoring U.WorkPlan
    claimGraph: U.ClaimGraph
      = dependency-position claims and their availability, relevance, value,
        governing-pattern, acquisition-condition, and next-use-boundary claims
    effectiveReferenceScheme: U.ReferenceScheme
      = interpretation of those claims for the declared next authoring use
  claimScopeRef: ClaimScopeRef governed by A.2.6
  intendedReaderDescriptionRef: U.EpistemeRef
  intendedFirstUseDescriptionRef: U.EpistemeRef
  dependencyPositions[3..*]: FrameworkAuthoringDependencyPosition
  nextAuthoringUseBoundaryDescriptionRef: U.EpistemeRef
  modelUseStructureRef?: U.StructureRef
    only when one selected BoundedModelUseStructure changes interpretation for this use
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
    only for separately obtaining C.2.1 empirical-grounding relations

FrameworkAuthoringDependencyPosition:
  dependencyPositionKey: semantic key unique within claimGraph
  dependencyKind: FrameworkAuthoringDependencyKindValue
  dependencyAvailability: FrameworkAuthoringDependencyAvailabilityValue
  dependencyUseRelevance: FrameworkAuthoringDependencyUseRelevanceValue
  dependencyValueRef?: U.EntityRef
  dependencyValueKindRef?: U.KindRef
  dependencyGoverningPatternRef: U.EpistemeRef constrained by A.3.2 to U.MethodDescription
  dependencyAcquisitionConditionDescriptionRef?: U.EpistemeRef

FrameworkAuthoringDependencyDescription is a local use label for one exact C.2.1 episteme, and each FrameworkAuthoringDependencyPosition is a local ClaimGraph node form rather than a U-kind, entity, relation occurrence, or package member. The description's current authoring WorkPlan EntityOfConcern, one ClaimGraph, and effective ReferenceScheme supply identity. ClaimScope, reader and use descriptions, optional model-use structure, empirical grounding, A.7 provenance, F.15 dependency-assessment status when current, publication, and edition continuity remain separate. A different empirical ground or use frame does not become an identity field; changed ClaimGraph, EntityOfConcern, or effective scheme identifies another episteme.

FrameworkAuthoringDependencyKindValue is fpfCoreEdition | sourceBasis | frameworkArchitectureDecision | nameRoute | patternDraftSet | relationAndEditionRecords | publicationOrAccess | packageQuality | improvement | currentness. FrameworkAuthoringDependencyAvailabilityValue is available | missing. FrameworkAuthoringDependencyUseRelevanceValue is currentForNextAuthoringUse | retainedForLaterUse | relevanceUnsettled.

The minimum three positions are exactly one fpfCoreEdition, one sourceBasis, and one frameworkArchitectureDecision. The architecture-decision position and the Core-edition position are available and carry exact value and kind refs; otherwise the post-PFAD dependency description is not yet admissible. The source-basis position follows the ordinary availability and relevance branches below and may therefore expose a blocking missing source pack. Add another dependency kind only when the declared next authoring use relies on that dependency or deliberately retains it for a named later use.

When dependencyAvailability=available, the exact dependency value ref and kind ref are present and dependencyAcquisitionConditionDescriptionRef is absent. When dependencyAvailability=missing, the value ref and kind ref are absent and the acquisition-condition description is present. Next-use relevance remains independent in both branches: missing + currentForNextAuthoringUse blocks the next authoring use and opens the stated return, while missing + retainedForLaterUse does not block the current use. A condition on using an available dependency belongs to that dependency's direct governing pattern or to the next-use boundary, never to the acquisition position.

Every admitted dependency description contains a frameworkArchitectureDecision position with availability=available and the exact E.4.PFAD decision ref and kind, and an fpfCoreEdition position with the exact selected Core-edition ref and kind. A missing PFAD returns to E.4.PFAD and prevents construction of the description. A missing or unsettled Core-edition decision returns to the dependency boundary settled by E.4.PFAD and E.4.PFR before this description resumes.

As authoring proceeds, the same description may refer to E.4.PFAD architecture decisions; E.4.PFR relation records and edition dependencies; G.2 source packs; subject-home NameCards; E.8 pattern drafts; E.24.PUB/E.11/E.17 publication or access uses; E.4.DPF.DA evaluation results; E.23 improvement results; and G.11 currentness relations. Each dependency value, relation occurrence, evaluation result, edition relation, and receiving use remains governed and identified separately. The description is neither the framework episteme edition, its package architecture, a publication occurrence, publication form, carrier, dated authoring Work, nor a substitute for any dependency value.

#Archetypal Grounding

Tell: A hydroponic-cucumber framework begins with crop-production concerns, horticulture and greenhouse-control sources, local examples, and FPF Core dependency. Its first all-in-one publication carrier is for domain users, while relation records, source packs, and quality evaluations remain separately recoverable.

Show: A neural-network architecture framework may draw on dataflow architecture, model components, training and inference concerns, evaluation practice, and recent architecture-analysis work. The framework can describe layers, blocks, flows, optimization constraints, and interpretability concerns; each resulting pattern is grounded through G.2, drafted through E.8, and related through E.4.PFR.

Show: A workspace-specific Codex process framework can contain prelanding and baton-handoff patterns. It should state its local context, dependency on FPF Core, process sources, local carriers, and refresh route. A useful local checklist stays a local checklist until it has source grounding, pattern bodies, relation records, and quality evaluation.

Show: An enterprise local practice framework for architecture review starts from the organization's review context, internal policies, proprietary examples, and approval path. It can depend on FPF Core and on a domain principle framework, but its confidential evidence, role assignments, training plan, and rollout telemetry stay local.

Enterprise local-practice slice:

Replayable authoring slice:

#Local-mantra authoring slice

After the HC.NutrientMonitoring Solution is stable, its authors use the local mantra: Name the crop stage and root-zone condition; establish that the measurement is usable in its current calibration range; compare it with the stage-specific range; change the control setting only within the declared operating boundary; return when crop stage, sensor validity, or operating boundary changes. The formula helps a grower or crop-system architect keep the pattern's operative distinctions and return condition in attention. It remains Plain wording inside HC.NutrientMonitoring; it is not another nutrient-control method, work order, U-kind, or F.17 publication obligation.

If a seminar instead needs to show alternative continuations for invalid measurement, out-of-range nutrient condition, control saturation, and crop-stage transition through one named wider unfolding structure, the authors open A.22.CGUS and build a demonstrative walkthrough. They do not obtain that structure merely by extending or repeating the local mantra.

#Pre-PFAD proposal slice

A team intends a new clinical-method DPF but has not decided its framework architecture. It creates one current U.WorkPlan for possible future DPF-authoring Work, then one C.2.1 IntendedFrameworkResultDescription whose identity is its exact intended-result ClaimGraph, that WorkPlan as EntityOfConcern, and its effective ReferenceScheme; ClaimScope remains separate. FrameworkOrganizationDesignProposal uses that description as its EntityOfConcern and proposes candidate pattern-family, dependency, publication, and access relations in one ClaimGraph. The proposal is the current result. No future framework entity, actual architecture, architecture description, dated Work, or production relation is asserted.

#Coverage and acceptance slice

The proposal's medication-review coverage criterion names the pattern families whose representation is necessary for that declared use. One constraint claim node names the covered relation-family refs with exact kinds, that admitted use, and the coverage criterion. The authoring WorkPlan separately cites an acceptance target for review completion. C.33 uses the coverage node as comparator when evaluating proposal coverage; the WorkPlan target does not replace the criterion.

#Empirical-grounding and use-frame stress slice

The intended-result description has a separately obtaining EpistemeEmpiricalGroundingRelation to MedicationReviewTeam@Hospital-A, an A.1-admitted holon, covering the exact supported claim subgraph. The holon is not an episteme identity slot. A request to rely instead on a consortium first rechecks the empirical-grounding relation and evidence, effective ReferenceScheme, ClaimScope, and any independently selected BoundedModelUseStructure. Changing only the empirical ground changes that relation; changing the ClaimGraph, EntityOfConcern, or effective scheme identifies another episteme. F.9 opens only if an exact cross-context local-sense translation is actually current, not merely because the maintaining organization changed.

#Post-PFAD dependency slice

PFAD exists. The Core edition is available and relevant now, so its dependency position has exact value and kind refs and no acquisition condition. A publication carrier is missing but retained for later use, so its position has no value refs, has an acquisition-condition description, and does not block current pattern drafting. A missing source pack marked currentForNextAuthoringUse blocks the next use and opens the stated return. Availability never stands for relevance.

#Framework-evolution slice

A new controlled-environment study changes the admissible nutrient range used only by HC.NutrientMonitoring. G.2 first revises the source-use decision and preserves the displaced source reading. E.4.PFR identifies the nutrient pattern, its source-reuse relation, and its dependent examples as the affected set. E.21 evaluates the revised pattern body; E.23 governs repeated improvement of that pattern edition; G.11 governs currentness, telemetry, and deprecation or supersession of exposed editions. Unaffected climate-control and harvest-feedback patterns remain current. E.4.PFAD stays closed while framework family, pattern split, relation structure, publication or access architecture, and dependency boundary remain unchanged; a change to one of those decisions makes PFAD current again.

#Bias-Annotation

The first drift is source-summary confidence: a summary feels sufficient because it names the right domain terms. The repair is to turn sources into a G.2 source pack with adopted and rejected payload, then carry that payload into pattern solutions and examples.

The second drift is publication-carrier-first authoring. The repair is not to delay publication forever; it is to publish after the architecture decision, relation records, and source-return notes are recoverable.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

Adoption risk tripwires:

#Consequences

Using the exact authoring Method and MethodDescription while keeping dated Work, results, receiving uses, editions, relations, package architecture, and publication objects explicit adds overhead before a local framework becomes durable. That overhead prevents hidden source loss, hidden Core change, hidden relation semantics, false production or membership claims, and hidden currentness debt.

The pattern also makes local publication more useful. Readers get a coherent publication or practical-use carrier, while maintainers can still inspect the framework edition, source pack, relation records, decision records, and quality route.

#Rationale

Domain and local frameworks are not mere subsets of FPF. They are FPF-grounded framework editions for declared domain or local use frames. They need domain source work, FPF authoring discipline, architecture decisions, relation records, quality loops, and refresh routes.

Its contribution is one E.8/A.3.2 framework-authoring MethodDescription plus precise Plain selection and branching guidance. The text does not claim a reusable condition-governed structure by prose; when an A.22.CGUS is genuinely current, it is separately admitted with exact conditions, continuations, stops, and demonstration. Every produced or selected result still needs an exact receiving use and the direct pattern governing that result or use relation.

#SoTA-Echoing

External-source currentness front. The current-FPF row above keeps its own exact recheck trigger. Apply each external-source decision only within the role and qualification basis below. When the named smallest change occurs, use G.11 to reopen only the affected authoring step, case, boundary, or adopted decision and return the changed source role to G.2; publication of a newer item alone is not a material trigger.

#Relations

• Uses: G.2 for source pack and SoTA synthesis.
• Uses: A.3.1 and A.3.2 for the exact framework-authoring Method and this MethodDescription; A.15.1, A.15.PROD, and A.6.1 for dated authoring Work, any local inception/result claim, and actual application/bindings; and E.8, E.10, and F.18 for pattern drafting, kind discipline, and names.
• Coordinates with: E.4 for family membership and E.4.PFAD for architecture decisions.
• Coordinates with: C.2.1 and A.2.6 for framework/result episteme identity, effective ReferenceScheme, empirical-grounding relations, and ClaimScope; A.1.1/A.22 only for an independently selected model-use structure; A.22.CGUS only for a genuinely admitted conditional unfolding; E.4.PFR for separately governed relation records, dependency, edition, compatibility, deprecation, and supersession effects; C.30.AD for post-existence architecture-description use and its retrieval-only project card name; and E.24.PUB for publication occurrence, form, and carrier.
• Coordinates with: C.33, C.34, and C.35 for carrier preservation and admission.
• Coordinates with: E.22 for quality-evaluation framing when needed, E.4.DPF.DA for DPF package adequacy, E.21 for pattern-quality evaluation, E.23 for repeated improvement, E.19 for admission or profile gating when claimed, and G.11 for currentness.
• Exits to: E.11 and E.17 when the live problem is practical-use or publication discoverability rather than framework authoring.

#E.4.DPF:End

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