FPF Reference

    Principle-Framework Architecture Decision

    E.4.PFAD · 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 an author is choosing among a new or revised principle framework, a contribution to an existing framework, another product that is not a framework, a thinner publication or access route, and no new maintained product now, and that choice will settle an identity, edition, relation, intended-use, or publication decision that later work must use. The decision may concern the public field and first use, framework edition, dependencies, initial pattern placement or relations, the kind and identity or change rule of a non-framework product, or the publication or access consequence. Another author or reviewer must need the answer and its rationale for later action.

    Relations

    E.4.PFADbuilds onFPF Ecosystem Family Architecture
    E.4.PFADbuilds onDesign-Rationale Record (DRR) Method
    E.4.PFADcoordinates withDomain Principle Framework Authoring and Publication-or-Access Carrier Assembly
    E.4.PFADcoordinates withPattern-Framework Relation and Edition Discipline
    E.4.PFADcoordinates withPractice Architecture Synthesis from Several Structures
    E.4.PFADcoordinates withProject Architecture Decision After Candidate Synthesis
    E.4.PFADcoordinates withArchitecture Decision Record Projection
    E.4.PFADcoordinates withMulti‑View Publication Kit
    E.4.PFADcoordinates withOntic Description and Publication Discipline
    E.4.PFADcoordinates withLocal-First Unification Naming Protocol
    E.4.PFADcoordinates withSoTA Harvester & Synthesis
    E.4.PFADcoordinates withTelemetry-Driven Refresh & Decay Orchestrator
    E.4.PFADcoordinates withFPF Pattern-Quality Evaluation CharacteristicSpace
    E.4.PFADcoordinates withPattern Quality Gates: Review and Refresh Profiles
    E.4.PFADcoordinates withOntology-First Plain Technical Rewriting
    E.4.PFADoutline parentFPF Ecosystem Family Architecture
    E.4.PFADoutline prev siblingFirst Principles Framework Form and Publication-or-Access Carrier Assembly
    E.4.PFADoutline next siblingDomain Principle Framework Authoring and Publication-or-Access Carrier Assembly
    E.4.PFADexplicit referenceDesign-Rationale Record (DRR) Method
    E.4.PFADexplicit referencePractice Architecture Synthesis from Several Structures
    E.4.PFADexplicit referenceDeveloping Capability for a Named Work Family
    E.4.PFADexplicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.4.PFADexplicit referenceFunction and Functional Precision Restoration (RPR-FUNCTION)
    E.4.PFADexplicit referenceArchitecture Structural View Adequacy (ASV)
    E.4.PFADexplicit referenceGamma_method - Order-Sensitive Method Composition and Work Enactment
    E.4.PFADexplicit referenceModule Relation Repair
    E.4.PFADexplicit referenceU.Transformation: Bounded Change Under Conditions
    E.4.PFADexplicit referenceTransformation Flow Structure
    E.4.PFADexplicit referenceThe Agential Role & Agency Spectrum
    E.4.PFADexplicit referenceU.Work: Dated Performed Work Occurrence
    E.4.PFADexplicit referenceSystemRoleAssignment and Performed-Work Attribution Check
    E.4.PFADexplicit referencePattern-Framework Relation and Edition Discipline
    E.4.PFADexplicit referenceProject Architecture Decision After Candidate Synthesis
    E.4.PFADexplicit referenceArchitecture Decision Record Projection
    E.4.PFADexplicit referenceMulti‑View Publication Kit
    E.4.PFADexplicit referenceOntic Description and Publication Discipline
    E.4.PFADexplicit referenceFPF Ecosystem Family Architecture
    E.4.PFADexplicit referenceDomain Principle Framework Package-Adequacy Evaluation CharacteristicSpace
    E.4.PFADexplicit referenceDomain Principle Framework Authoring and Publication-or-Access Carrier Assembly
    E.4.PFADexplicit referenceDPF Suite Reference
    E.4.PFADexplicit referenceNeeded Relation Claim Derivation and Relation-Kind Admission
    E.4.PFADexplicit referenceRelation Obtaining and Individuated Relation Occurrences
    E.4.PFADexplicit referenceStructure and Structural Views (STRUCT-CAL)
    E.4.PFADexplicit referenceStratification Wording Precision Restoration
    E.4.PFADexplicit referenceArchitecture Description Adequacy
    E.4.PFADexplicit referenceCultural Evolution and Cultural-Evolution Engineering
    E.4.PFADexplicit referenceLocal-First Unification Naming Protocol
    E.4.PFADexplicit referenceSoTA Harvester & Synthesis
    E.4.PFADexplicit referenceTelemetry-Driven Refresh & Decay Orchestrator
    E.4.PFADexplicit referenceFPF Pattern-Quality Evaluation CharacteristicSpace
    E.4.PFADexplicit referenceQuality Improvement Loop Method
    E.4.PFADexplicit referencePattern Quality Gates: Review and Refresh Profiles

    Content

    Problem frame

    Use this pattern when an author is choosing among a new or revised principle framework, a contribution to an existing framework, another product that is not a framework, a thinner publication or access route, and no new maintained product now, and that choice will settle an identity, edition, relation, intended-use, or publication decision that later work must use. The decision may concern the public field and first use, framework edition, dependencies, initial pattern placement or relations, the kind and identity or change rule of a non-framework product, or the publication or access consequence. Another author or reviewer must need the answer and its rationale for later action.

    E.4.DPF may return this question before a public product name, PatternIDs, or pattern bodies exist. Open it when preliminary exact subtraction leaves exact ownership unresolved, a coherent connected remainder, or a material field, relation, source or refresh, publication, or access consequence that later work must use. Treat an incoming carrier or organizing cue—for example, a role account, MethodDescription, file, Card, mantra, shared topic, or missing authoring artefact—as evidence for that comparison. Decide the outcome from exact candidate contributions and the later-used consequence.

    Here product has the Plain management meaning declared in E.4:4.1; it is not a technical kind. When a non-framework product is selected, the answer names its direct subject, kind, and the identity, current-state, provision, publication, availability, or other relations used by the decision. Name a maintenance relation only when that stronger claim separately obtains and changes the answer. If a kind or relation that can change the answer is unresolved, keep it as an explicit decision question and do not invent U.Product.

    A proposed new or substantially revised DPF also needs an answer about its field boundary. That answer says who can first use the framework and for what, which connected problem families and useful results it covers, what the current FPF and admitted DPFs already provide, and what remains uncovered. It compares serious alternatives, tests one representative case that crosses problem families, states where the evidence runs out, and names the change that will require a refresh. Together these must support one independently usable pattern language. One pattern or a narrow authoring slice is not a DPF merely because it has a broad title or a coherent carrier.

    If a cheap search, curated reading route, useful contribution to an existing framework, suitable non-framework product, or stop answers the immediate need without settling such a boundary, use that result and stop. Reserve the framework-architecture DRR for a later-used boundary.

    When the architecture question is live, use E.4.PFAD to state the framework-specific content of one ordinary E.9 DRR. The decision-maker selects the answer during decision Work; that DRR is its decision record. This practitioner-facing profile locates the questions and answer content inside the DRR, while acceptance remains a separate decision.

    Problem

    Framework authors repeatedly need to decide whether a recurring practitioner problem calls for a new framework, an existing framework contribution, another product such as a programme, service, or evidence package, a thinner access result, or no new maintained product now. When a framework is selected, later work needs its public field promise, first-edition boundary, FPF Core dependency, problem-family coverage, first patterns and their material relations, representative use, important omissions, and publication or access consequence. Generic decision prose can hide those choices.

    A small coherent authoring slice creates a common false positive: its few current patterns and neat structure are mistaken for a field-scale pattern language. Source diagrams create another: one list or hierarchy is copied into the DPF although Methods, Work, subjects, descriptions, capabilities, providers, and cultural change may have different structures. A large framework-specific form creates the opposite problem by making proposal, acceptance, DRR, edition, authoring, quality review, and publication look like one extra decision object.

    The useful result is one readable answer whose framework consequences and limits are visible without adding a second decision stage or making cheap exploratory work produce decision paperwork.

    Forces

    ForceTension
    DiscoverabilityAuthors need a recognizable framework question, but a locator must not become another decision object.
    Framework scaleA narrow pattern set can be useful, but a broad public framework needs connected problem-family coverage, a first use that does not depend on unpublished authoring context, and a stated reason for later refresh rather than a pattern count.
    Several structuresA decision needs one coherent practice-architecture answer, but Method, Work, subject, description, capability, provider, and cultural structures need not line up one-for-one.
    Decision memoryLater work needs rationale and consequences, but the DRR is not the accepted answer, performed authoring, or framework edition.
    Framework detailEdition, dependency, pattern placement, relations, omissions, the sources that later authors must be able to revisit, and publication consequences matter, but unrelated quality, naming, and package apparatus must stay conditional.
    Cheap exitA suitable non-framework product, small access result, or existing-framework contribution may solve the immediate problem without a framework decision.
    Relation precisionInitial pattern relations may shape the architecture, but a row or schema does not make those relations obtain.
    EvolutionThe answer needs a reopen condition without turning every refresh concern into a mandatory field.

    Solution

    Decide whether the architecture question is open

    Ask whether choosing a framework, a non-framework product, a thinner route, an existing-framework contribution, or stop will settle at least one decision used by later authoring or review:

    • the public field promise, a first use that does not depend on unpublished authoring context, or the problem-family coverage of a proposed DPF;

    • an intended or existing framework edition;

    • an FPF Core or other current edition dependency;

    • initial pattern placement or a material relation among those patterns that changes the architecture;

    • the direct subjects and identity or change rules for a continuing programme, an admitted service, or a separate editioned result, plus any maintenance relation when later work separately claims or uses it;

    • a publication or access consequence; or

    • for a proposed DPF Suite, the ecosystem use, which product series may belong, constitution, inclusion and removal rules, identity through change, source return, later-review and retirement conditions, exposure choice, any separate DPF Suite Reference product decision, and any maintenance relation only when separately claimed.

    When E.4.DPF supplies a preliminary contribution account, use the contributions rather than their carrier as the input. If same-situation comparison shows that exact current FPF or admitted-DPF owners carry every action, first result, return, and source or refresh duty—or exact external results supply them—and no decision above remains, take the smallest useful result and close without PFAD. Keep the architecture question open when exact ownership remains unresolved, a coherent action-bearing remainder survives, or closure would erase a material relation or field or refresh responsibility that changes a later use. Carrier form, role label, shared topic, naming and PatternID state, and counts locate candidate contributions. The four dispositions and later-used consequence determine whether to close or select an outcome.

    If none of these decisions and no receiving use are present, take the exploratory result as the answer. If one is present, the decision-maker selects a framework, non-framework product, thinner route, existing-framework contribution, or stop during decision Work, and one E.9 DRR records that answer. The cheap exit and the architecture decision are alternative entry outcomes.

    For every product alternative, use product only as the first management cue. Then compare the direct subjects at the same grain: the exact framework or package episteme, System, service arrangement, Method, programme description, carrier, or other admitted result, and the relations that later work will rely on. Use a quality-management, service-management, publication, or content-management scheme as a probe; use the FPF direct-subject patterns to settle the kind. If an unresolved kind can change the selected answer, keep the product proposed and make that kind the next decision question.

    State the compact framework answer

    When the architecture question is open, the framework-specific part of the DRR states:

    1. the intended practitioner, public field name and promise, recurring problem, and bounded architecture question;

    2. the selected outcome: a new or revised framework edition, a contribution to an existing framework, a non-framework product, a thinner publication or access route, or no new maintained product now; for a non-framework product, also the direct subject kind and the identity, current-state, provision, publication, availability, or maintenance relations actually used by the decision;

    3. its field boundary: who can first use it without unpublished authoring context and for what; the connected problem families and useful results; what the current FPF and admitted DPFs already provide and what remains uncovered; serious alternatives, such as splitting or merging the proposed framework, using existing sources directly, contributing to one existing framework, composing exact contributions across several admitted DPFs and FPF, selecting a programme or service, selecting a separate evidence-package episteme, or selecting no new maintained product now; the limits of evidence; and what change will require a refresh;

    4. the selected problem-family pattern sets, first patterns and their material relations, representative cross-problem application, and important omissions;

    5. which practice structures change the answer and how their Methods, descriptions, patterns, direct subjects, and managed result boundaries fit together. When those structures do not line up one-for-one, use a completed C.32.MWA synthesis; use E.23.CDI only when capability development for a named Work family changes the answer;

    6. the existing or intended-edition boundary, selected FPF Core dependency, and only the other exact edition dependencies required by this answer;

    7. the sources to revisit for each important claim, whether the evidence supports, suggests, or only motivates it, the limits of that evidence, and the publication or access consequence; and

    8. material alternatives, accepted costs or losses, practical consequences, the first authoring action or stop, and the reopen condition.

    For any opened question, record only candidate contributions that can change the outcome. For each, state whether an exact current FPF or admitted-DPF owner carries its action, first result, return, and source or refresh duty; an exact external result supplies it; an action-bearing remainder survives; or ownership remains unresolved. A shared topic or broad framework name can locate candidates; assign a disposition only after exact contribution comparison.

    When professional Method coverage can change point 5, the same compact framework answer projects five connected claim groups from points 1, 3, 4, 5, 7, and 8. The projection remains content of that one answer and its one ordinary E.9 DRR. Fill each group to the grain that changes first use, using a representation suited to the case, before DPF authoring:

    1. Practice truth and first use: identify every bounded practice claim or promised practice contribution by its exact subject and scope, mark that claim—not the answer as a whole—as obtaining or possible-future, and state practitioner, recurring or anticipated difficulty, sought result, first use, stop or wrong-turn return, qualification window, and receiving decision. Include only non-use boundaries admitted by F.19's grounded-contribution test.
    2. Project and Method positions: name the direct project subjects, use and environment, materially different solution forms, and Methods under their actual operational, system-change, solution, Method-of-interest, or Method-development relations. Keep incumbent Work, development or trial Work, candidate-practice Work, and intended Work distinct.
    3. Selected structures and correspondences: include only the Method, Work, subject, transformation-flow, capability/provider, description, contribution, Method-development, and cultural structures whose correspondence, conflict, or non-isomorphism changes the answer.
    4. Pressures and evidence: keep constraints, conflicts, failures, environment or interest changes, and observed, source-supported, estimated, contradicted, and missing links distinct from causal history and temporal unfolding.
    5. Contribution, subtraction, gaps, and reopen: apply the four dispositions above, then name each receiving pattern and domain filling still needed, honest omissions and gaps, and the observation that reopens the architecture.

    Within an existing-framework contribution or another answer that selects no new framework, distinguish one existing DPF receiving a contribution from a use that composes exact contributions supplied by several DPFs and FPF. Record the latter as cross-DPF composition under the selected one of the five outcomes, optionally exposed through a role-centred view or access route. Decide Suite membership separately.

    One answer may contain several bounded practice claims with different truth status. Every selected practice question names the claim or claims it consumes, so an obtaining incumbent-practice claim can coexist with a possible-future candidate-practice claim without backdating the candidate or erasing current incumbent coverage. Independently obtaining A.13 agency claims and actual development or trial Work keep their own status; neither proves that the candidate practice obtains. Public coverage is another claim and remains limited to the exact obtaining or prospective contribution and later package evaluation.

    For an obtaining practice claim, name actual recurring difficulties and representative actual Work. A precise Agent-performer branch first supplies A.13's core: the exact admitted System, local agential system-role kind and criterion, classification, obtaining assignment, and needed scope, working situation, and window. Add the agency-characteristic profile only when a Grade, autonomy or profile claim, a criterion-dependent characteristic, or a named assurance use consumes it. A.15.1 then independently admits the actual Work from its performance history, Method, extent, and containment. Only after admission does F.6 supply any precise assignment-bound attribution through that same obtaining assignment. State evidence limits; a missing F.6 relation leaves admitted Work intact and only the attribution unresolved.

    For a possible-future practice claim, name intended use, incumbent Work or Method and observed problem evidence, candidate Methods and architecture, realization conditions, a planned representative trial, expected acceptance and failure observations, and reopen conditions. Any incumbent-practice or actual trial-Work claim stays independently obtaining when supported, but the candidate-practice Work, candidate-practice Agents, and current candidate-practice coverage remain unasserted until their own conditions obtain.

    For every selected question, name its receiving pattern and the exact bounded practice claim or claims whose values change first use. If a required group or claim-to-question binding is absent at that grain, return a bounded PFAD gap to the architecture decision for completion before DPF authoring. A completed C.32.MWA synthesis is used only when several selected structures do not line up one-for-one, and E.23.CDI only when capability development changes the answer.

    The answer is one identified claim-bearing episteme under C.2.1 and is recorded, with its rationale, in one ordinary E.9 DRR. The decision-maker selects that answer during decision Work. An authorized decision-maker accepts, redirects, rejects, or reopens it through a separately identified acceptance decision. Record that accepting decision separately and hand its exact accepted answer to E.4.DPF.

    Common practice questions include:

    Practice questionPattern that supplies or tests the answer
    What contribution or effect is required?A.6.F; use C.30.ASV only when a selected architecture view changes the answer.
    Which Methods construct a larger Method, and which genuine interfaces matter?B.1.5; use A.6.M only for a real module, port, or implemented-interface claim.
    What changed, and how are the transformation-flow positions related?A.3.4, E.18, and C.30.TFS-REL.
    What Work occurred, which Method did it enact, and who performed it?A.13 followed by independent A.15.1 admission; F.6 only afterward for precise assignment-bound attribution, with the A.13 profile branch only when consumed.
    Which System has the needed capability, and what did a provider actually contribute?A.2.2 plus the applicable Work, provision, or service pattern.
    What cultural generation, transmission, reconstruction, recognition, selection, retention, or loss matters?C.36.

    If another question changes the answer, name it and the pattern that handles it. A required contribution, transformation, performed Work, capability, provider contribution, or cultural change belongs to its own pattern; B.1.5's complete relation predicate supplies Method parthood. For a DPF Suite answer, an architecture decision takes effect to constitute the continuing collection. It selects the ecosystem use, which product series may belong, inclusion and removal rules, identity through change, alternatives, practical consequences, and the reopen condition. The same E.9 DRR records that answer. Publication and availability of the first or a later edition are separate occurrences. A maintained-Suite claim separately identifies the maintenance relation, capable System, any commitment that actually obtains, and the refresh response. For any current or available Suite claim, apply E.4:4.2's direct currentness, availability, and source-return conditions, including return to every product-series state presented as current. When the answer selects exposure, choose an independent Suite route, a bounded projection in a current DPF Suite Reference edition with source return, or a neutral combined carrier. Constituting and including the Reference product series, admitting its editions, publishing them, making them available, maintaining them, and refreshing their answers remain separate decisions and claims. Record a proposed result use or future constraint as such; apply E.4.PFR after edition-level case facts establish a dependency or compatibility relation.

    For an existing-framework contribution, non-framework product, thinner route, or stop, state only the parts needed to explain that outcome and the later-used decision. A selected product still names its direct subjects and the relations used; a proposed product with an unresolved kind says so. The selected outcome determines which field-assessment or package content applies.

    When the architecture keeps, merges, removes, reuses, or omits a load-bearing contribution, record the E.8:4.1.3 same-situation disposition and the action or result that changed. Preserve a difference when it changes action at comparable effort without adding an unsupported or needless burden. A narrower label or example alone is not that difference.

    When the answer treats a promised problem family as covered by a result supplied from outside the framework, name the exact result, its exact relied-on content and direct kind, supplying product and exact edition or current state, receiving use, practical discovery route, and every currentness or availability condition that can change that use. State that the result remains external, and state maintenance only when it changes the receiving use. When the receiving use requires an availability or compatibility result, name that exact result and its exact basis. If those facts are absent, or the result does not answer the promised use, record a gap or omission rather than relabelling the result as framework content, a MethodDescription, or source evidence. When the selected keep, merge, removal, profile, external reliance, or omission materially changes the stable set for a promised problem family, obtain a current E.4.DPF.DA D12DomainProblemFamilyCoverageAdequacy result for the resulting exact DPF or LPF edition. Reuse a matching current result while that exact resulting edition and basis are unchanged. Do not require proof that a revisit occurred.

    Keep the ordinary E.9 grounds, sources, affected loci, rationale, and consequences in the same DRR. Add naming, quality, admission, currentness, or package details only when they change this answer or a named later use requires them. Each added claim remains under the pattern that defines, constrains, or tests it and appears in PFAD for that named use.

    State initial pattern relations directly

    When an initial pattern relation changes the selected architecture, state the relation and its participants as an ordinary assertion. For example: Pattern A frames the recurring problem; Patterns B and C specialize its reusable move for two stated situations. Use the pattern that defines or constrains each relation function.

    For the architecture answer, use the direct assertion under the relation's own predicate. Add an optional E.4.PFR row when a named maintenance use needs that representation.

    Keep the answer, DRR, authoring, and publication distinct

    The decision-maker selects the answer during decision Work. The E.9 DRR records that answer and its rationale. An authorized decision-maker accepts, redirects, rejects, or reopens it through a separately identified acceptance decision. Later authoring follows an accepted answer. A framework edition is the pattern-language episteme assembled from accepted sources; any maintenance relation obtains separately. Publish or project claims about these objects in the selected form—for example, an ADR-like document, site, or PDF—and identify its presentation carrier separately when needed.

    When the answer uses C.32.MWA or E.23.CDI, keep each proposed Method distinct from the pattern that describes it, the Work in which it is performed, the result of that Work, the framework answer, the DRR, and the resulting edition. Use a proposal or evidence locator to find the supporting material.

    Use C.32.PAD only when the question is an exact project architecture decision about a named composite project Work, and use C.32.ADR only to project that project decision. For an ordinary framework answer, publish the selected decision episteme or a reader-specific projection through E.17 and E.24.PUB. None of these is a mandatory stage of principle-framework authoring.

    Archetypal Grounding

    Positive DPF

    A systems-management group considers a public DPF for recurring problems in service launch, cross-team coordination, incident response, and feedback-based improvement. A broad FPF route covers several shared distinctions, and an admitted neighboring DPF covers one specialist branch, but neither gives this practitioner group a coherent first use across the four problem families. The field-boundary assessment compares a new DPF with direct FPF-and-source use, a guide, contribution to the neighboring DPF, two existing DPF edition series, and no new maintained product now. It favors one DPF because a representative service-launch case needs patterns from several problem-family sets together and has an independent edition, change, and refresh boundary, including its later-review rule.

    The source accounts organize Methods, dated Work, service and equipment subjects, descriptions, provider capabilities, and cultural change differently. A completed C.32.MWA result makes those correspondences and conflicts readable; the selected problem families and relations supply the DPF structure. The E.9 DRR records the public promise, selected problem-family sets and material relations, representative case, Core and other exact dependencies, omitted procurement and certification questions, the sources to revisit, which claims the evidence supports, suggests, or only motivates, the publication consequence, first authoring action, and reopen condition. Capability development does not change this case, so E.23.CDI is absent. PFR rows and proposal locators serve their conditional representation and discovery uses.

    Exploratory access result

    Existing FPF and source material answer the immediate need through a curated route. The inquiry closes with that route because no later author or reviewer needs a settled framework boundary.

    Decision-level access result

    A team needs a settled choice among a DPF, an access route, and stop because later work depends on the rationale. The architecture question is therefore open. The team selects the access route and no new framework edition. One E.9 DRR records the selected access consequence, stop, and condition for reconsidering the answer.

    Non-framework programme product

    A cross-domain inquiry need recurs, but practitioners do not need another pattern language. The decision compares a DPF, an inquiry-programme product, a separate inquiry evidence-package episteme, a curated route, and no new maintained product now. It selects the programme because named users need continuing access to inquiry Methods, bounded-project intake, and result return. The answer records the programme's admitted direct subject and relations under their owning patterns. Any maintenance relation is a separate claim.

    Its first usable version is a current programme-description episteme that names the users and questions, inquiry Methods, project intake, result return, access, change, and retirement rules. Name any provider System, maintenance relation, accepted commitment, or admitted service state when it independently obtains and changes the answer. Each bounded inquiry project requires independent A.15.1 admission as a separate Work occurrence, and each returned result is a separate episteme. A subject pattern may instead admit the programme itself as a System or another exact arrangement, in which case the answer names it. A bounded project may end while the managed programme continues and evolves. The inquiry evidence package remains its own editioned episteme.

    DPF Suite and Reference

    Three separately constituted DPF product series already cover one recurring practitioner use. The live architecture question is Suite constitution and membership for their shared ecosystem use. When one architecture decision takes effect, it constitutes the continuing Suite collection, states its ecosystem use, defines which product series may belong, selects inclusion and removal rules and identity through change, and chooses source return and exposure. Its E.9 DRR records that answer and the initial inclusion decisions. Each DPF edition still belongs to its own product series under that series rule. The answer separately decides whether a DPF Suite Reference product series is constituted and included and states its edition-admission, source-return, later-review, and retirement rules. Publication and availability are separate occurrences. A maintenance relation, maintaining System, or commitment is recorded only when it separately obtains. A Reference edition may then give a problem-led cross-DPF answer; Suite constitution and membership remain with the Suite decision. Record a proposed cross-DPF result use as such, then apply the edition-level dependency or compatibility predicates when their case facts exist. A later author returns an inclusion or removal proposal to the Suite decision, which settles that membership.

    Existing framework

    A local practice framework already has an accepted architecture answer and a source record. Reopen when its selected edition boundary, dependencies, initial pattern architecture, or publication or access consequence changes; otherwise, an example or publication-carrier edit follows the existing answer.

    Candidate recognition before product form

    These cases apply the same contribution comparison at a carrier- or count-shaped entry.

    Incoming materialPreliminary comparisonFramework result
    A MethodDescription for composing recommendations covers a receiving question and authority, qualified supplier results, alternative formation, a declared comparison, a bounded recommendation, later-choice separation, and affected-premise refresh.Compare those contributions with current framework content. Use the file, MethodDescription, and broad title to locate candidate contributions; planned or unavailable pattern content leaves the corresponding contribution unresolved.Keep the architecture comparison open until exact current contributions support an outcome; select an owner from those contributions.
    One long-mantra Card keeps several recurring problem–move–result contributions, material relations, representative cross-use, a plausible field, and a refresh boundary in attention.Treat the Card and mantra as evidence and run the same exact subtraction as for a larger carrier set.Apply the unchanged field-scale test; the Card is one carrier for its evidence.
    A practitioner working in one professional role combines contributions from several current DPFs and FPF.Recover the role meaning and the exact contributions. Every action, result, return, and refresh duty is carried, and no coherent independent remainder or distinct field promise survives.Reuse the cross-DPF composition, with a role-centred view when needed; no new DPF is warranted.
    One composite Method or local procedure has several ordered steps for one recurring problem/result family.Keep the Method, MethodDescription, carrier, Work, and listed steps distinct. The contribution remains one recurring problem/result family at Method scale.Return the smallest exact non-framework result or stop; use the cheap exit when no later-used architecture consequence remains.

    Bias-Annotation

    Scope: limited. This profile decides a later-used architecture boundary for an FPF-grounded framework, adjacent result or service, thinner route, existing-framework contribution, or stop. It does not provide a universal product ontology, a service-design Method, a publication taxonomy, or a mandatory decision form for exploration.

    The first drift is form-first decision making: a team starts from a schema, row, ADR heading, or status field and assumes that filling it has settled the architecture. Start from the reader's problem, alternatives, later-used boundary, and practical consequence instead.

    The second drift is machinery-first entry: proposal, dependency, quality, naming, and publication apparatus appears before the reader knows whether a framework decision is needed. Keep that apparatus conditional on its own receiving use.

    The third drift is slice-as-product: the small set currently being authored receives a broad DPF name before its field promise, several problem families, representative first use, omissions, and refresh boundary have been tested. Treat the slice as a seed or existing-framework contribution until the field-boundary assessment supports a DPF.

    The fourth drift is architecture-by-layout: source rows, levels, chapters, or diagrams become the product structure. Recover the Methods, Work, subjects, descriptions, capabilities, providers, cultural change, and their actual relations first; use C.32.MWA when several structures must be reconciled.

    The fifth drift is relation-by-representation: a table row or reference list is treated as the relation it records. State the relation directly; add a representation only when a named maintenance or checking use needs it.

    LensDeclared bias and counter-check
    GovFavors one later-used decision with explicit rationale, any responsibility or maintenance relation that changes the answer, and a reopen condition. Counter-risk: every exploration becomes an approval exercise. Keep the cheap exit and require a DRR only when later work needs the settled boundary.
    ArchFavors comparison among framework, existing-framework contribution, adjacent result or service, thinner route, and stop. Counter-risk: every useful result becomes its own framework or product. Select the smallest independently useful boundary and keep carriers, frameworks, services, programmes, and evidence packages distinct.
    Onto-EpistFavors direct subject kinds and actual identity, current-state, provision, maintenance, dependency, and publication relations. Counter-risk: the decision becomes an ontology inventory. Use product as Plain management wording, name only distinctions that change the answer, and return an unresolved-kind question rather than minting U.Product.
    PragFavors representative first use, serious alternatives, evidence limits, omissions, and one next action. Counter-risk: product-line, service-management, bibliographic, or content-management apparatus dominates a small decision. Reuse only the external distinctions that discriminate among the live alternatives.
    DidFavors a recognizable working question and filled unlike cases before assurance detail. Counter-risk: compressed labels hide the object boundary, while formal precision hides the decision. State the ordinary alternative first, then explain the exact subject in one direct sentence.

    Conformance Checklist

    CheckPassing condition
    CC-PFAD.1 Opening discriminatorA later-use field promise, edition, dependency, pattern placement or material relation, non-framework direct subject or identity/change rule, separately claimed maintenance relation, or publication or access decision makes the architecture question live.
    CC-PFAD.1a Carrier-neutral openingA live question may arrive before a product name, PatternIDs, or pattern bodies. Carrier, role, topic, cue, and count supply evidence for locating candidate contributions. Exact subtraction plus a later-used consequence opens PFAD; when every contribution is carried or supplied externally and no such consequence remains, the cheap result closes.
    CC-PFAD.2 Cheap exitA suitable available non-framework result or service, route, existing-framework contribution, or stop that settles none of those decisions closes without PFAD or a DRR.
    CC-PFAD.3 One decision recordDuring decision Work, the decision-maker selects a new or revised framework, contribution to an existing framework, non-framework product, thinner publication or access route, or no new maintained product now; one ordinary E.9 DRR records it.
    CC-PFAD.3a Field boundaryA selected new or substantially revised DPF has a reviewed field-boundary assessment. It names the practitioner and a first use that needs no unpublished authoring context, connected problem families and results, what the FPF and admitted DPFs already provide, what remains uncovered, serious alternatives, representative cross-problem use, evidence limits, the decision that uses the assessment, and the later observation that reopens it.
    CC-PFAD.3b Coverage, contributions, and omissionsThe answer names selected problem-family pattern sets, first patterns and material relations, one representative cross-problem application, important omissions, and the sources to revisit for important claims; no count or authoring slice proves adequacy. For each load-bearing contribution that it keeps, merges, removes, reuses, profiles, supplies externally, or omits, it applies E.8:4.1.3 and names the resulting action. An external return names the exact result, exact relied-on content, and direct kind, supplying product and exact edition or current state, receiving use, discovery route, and material currentness or availability conditions, and says that the result remains external. For any required availability or compatibility result, name that exact result and its exact basis; an insufficient return remains a gap or omission. After a material promised-family change, the answer obtains the current E.4.DPF.DA D12DomainProblemFamilyCoverageAdequacy result for the resulting exact DPF or LPF edition and reuses it only while the exact resulting edition and basis remain unchanged, without asking for evidence that someone revisited it.
    CC-PFAD.3c Professional-practice projection and several structuresWhen professional Method coverage changes the answer, the same compact answer projects five connected groups by value: claim-scoped practice truth and first use; project and Method positions; selected structures and correspondences; pressures and evidence; and contribution, subtraction, gaps, and reopen. One answer may carry several bounded practice claims with different obtaining or possible-future status, and every selected question names the claim or claims it consumes. The answer, one ordinary E.9 DRR that records it, and the separately identified accepting decision remain distinct. A missing required group or claim-to-question binding returns a bounded PFAD gap before DPF authoring. C.32.MWA is used only when several selected structures do not line up one-for-one and E.23.CDI only when capability development changes the answer. B.1.5's complete predicate supplies Method parthood. Realize the five claim groups by value in the one answer and ordinary DRR even when the source begins as a fixed view list, layout, or Method hierarchy.
    CC-PFAD.3d Direct-subject accountProduct remains Plain management wording. A selected product names every direct subject and the identity, current-state, provision, publication, availability, or other relation used by the answer. It names a maintenance relation only when that claim separately obtains and changes the answer. A programme case also distinguishes any provider System, maintenance relation, accepted commitment, or admitted service state that independently obtains, together with bounded Work and evidence-package epistemes. An unresolved kind remains an explicit question, not U.Product.
    CC-PFAD.3e Exact subtraction and compositionEvery outcome-changing candidate contribution is classified as carried by an exact current owner, supplied by an exact external result, an action-bearing remainder, or unresolved through same-situation action, first-result, return, and source-or-refresh comparison. A broad owner counts only when it carries those values. An existing-framework answer distinguishes one DPF receiving a contribution from cross-DPF composition. Record composition under one of the five outcomes and submit Suite membership to the Suite decision.
    CC-PFAD.4 Compact payloadThe DRR carries only the applicable content groups in E.4.PFAD:4.2 and ordinary E.9 grounds and rationale; the selected outcome determines the applicable fields for a non-framework product, thinner route, or stop.
    CC-PFAD.5 Direct relation assertionsRelations among initial patterns are stated directly under their actual relation functions; an optional PFR row represents them for a named maintenance use.
    CC-PFAD.6 Object boundariesAnswer, acceptance, DRR, authoring Work, Method results, edition, and publication remain distinct; proposal locators serve discovery. For a programme answer, the exact persisting subjects, any provider System, maintenance relation, accepted commitment, or admitted service state that independently obtains, each bounded inquiry Work occurrence, and each evidence-package edition remain distinct.
    CC-PFAD.7 Conditional apparatusNaming, quality, admission, currentness, and package details appear only when they change the answer or serve a named use.
    CC-PFAD.8 Reopen conditionThe DRR states what change in field boundary, framework architecture, evidence, or receiving use requires reconsideration.
    CC-PFAD.9 DPF Suite decisionA selected Suite answer states the ecosystem use, which product series may belong, Suite constitution, inclusion and removal rules, identity when product series change, source return, later-review and retirement conditions, exposure choice, alternatives, consequences, and reopen condition. It separately states edition-to-product belonging and whether a DPF Suite Reference product series has been constituted and included. A maintained-Suite or maintained-Reference claim separately states its supporting maintenance relation, refresh response, and evidence. Record belonging as collection membership; assert holonhood, constructive parthood, dependency, or compatibility only through its own complete predicate.

    Common Anti-Patterns and How to Avoid Them

    Anti-patternWhat failsRepair
    Carrier-first closure or automatic escalationAuthors treat a role, file, Card, mantra, MethodDescription, count, missing PatternIDs, or broad owner as grounds either to dismiss a possible pattern language before comparison or to force every multipart carrier into PFAD. An action-bearing remainder or cheap exit disappears.Recover candidate contributions through E.4.DPF:4 and compare exact actions, first results, returns, and source or refresh duties. Stop when subtraction closes and no later-used consequence remains; otherwise let the existing PFAD discriminator open the decision. Use the cue to locate candidates and select the outcome from their exact contributions.
    PFAD as a second decisionAuthors reconcile an E.9 answer with another PFAD result.Keep the decision-maker's one selected answer, recorded in one E.9 DRR; use PFAD only as the framework-specific profile.
    Paperwork on the cheap exitA curated route, suitable non-framework result or service, existing-framework contribution, or stop triggers a DRR without settling a later-used boundary.Close the exploratory use directly.
    Programme erased by a result-kind testA continuing inquiry programme is called no product because it is not an episteme or publication package.Keep the Plain programme-product boundary when it is useful. Name its admitted direct subject or current programme description and any provider System, maintenance relation, commitment, or admitted service state that independently obtains. Keep bounded Work and evidence-package epistemes separate.
    Product word used as the alternative's kindA programme, service, guide, registry, System, or episteme is selected as a generic Product without identifying the direct subject.Apply E.4:4.1; name the direct kind and relation, or keep the boundary proposed and return the unresolved question.
    External management scheme decides the FPF boundaryA QMS product category, full service-management system, bibliographic model, or content-management process is copied into every alternative.Reuse only the distinction that changes this decision and keep each claim under its direct subject pattern.
    Authoring slice as frameworkA few coherent current patterns receive a broad public field name.Keep them as a seed or contribution until a field-boundary assessment, representative cross-problem use, omissions, and a credible edition, change, and refresh boundary support a DPF.
    Source layout as product architectureRows, chapters, levels, or diagrams are copied into pattern sets or DPF structure.Recover the actual structures and relations; use C.32.MWA when they do not line up one-for-one.
    Proposal locator as Method or editionA proposal or evidence locator is treated as a Method, MethodDescription, accepted decision, or available FPF result.Name the evidence, Method, description, decision, and edition separately.
    Mandatory relation rowA PFR row is required before relations among initial patterns can be understood.State each relation directly and add a row only for a named maintenance use.
    ADR as decisionA publication projection is treated as the answer or acceptance.Name the answer and acceptance separately; use ADR only as a projection.
    Conditional detail made universalEvery decision must supply naming, quality, admission, currentness, and package records.Include only details that change this answer or serve a named use.
    Hidden Core changeA domain or local framework decision silently changes FPF Core meaning.State dependency direction and keep Core changes in their own accepted decision.

    Consequences

    Authors get a recognizable framework question, one cheap stop rule, one readable decision account, and one next action. Later authors can recover the public field promise, problem-family coverage, representative use, edition boundary, dependencies, initial pattern architecture, omissions, sources to revisit, publication or access consequence, rationale, and reopen condition without reconciling two decision objects.

    A new or substantially revised DPF carries more architecture work than a suitable non-framework product, thin route, or existing-framework contribution, and the PFAD profile adds one locator to maintain. That cost makes field-scale evidence explicit before a public pattern language is selected. Conditional naming, package, quality, and machine-readable detail stays out until a named use needs it.

    Rationale

    The PFAD locator makes recurring framework-specific questions discoverable. One ordinary E.9 DRR records the bounded answer, alternatives, rationale, consequences, action, and reopen condition.

    The field-boundary assessment reserves field-scale identity for a contribution with the practitioner coverage and independent use that justify it. The several-structure branch grounds the practice architecture in its actual Methods, Work, subjects, descriptions, capabilities, providers, and cultural relations. Direct assertions state each selected initial pattern relation under its own predicate; optional representations serve their named uses.

    PFAD is therefore the practitioner-facing profile for the framework-specific content of one ordinary E.9 DRR.

    SoTA-Echoing

    Practice questionBest-known lineSerious alternative or defaultDefect overcome and E.4.PFAD mutationSource roles and limitsReopen condition
    How should an author decide whether a reusable framework family boundary is worth settling rather than recording one current slice or applying a full software product-line method?Marchezan de Paula et al.'s 2022 systematic review is the best-known-line candidate for this bounded scoping question because it compares product, domain, asset, technical, organizational, and evaluation concerns across 41 approaches.One-slice authoring, label or pattern-count specificity, and a complete software product-line process are the serious alternatives.The first defaults hide promised-family coverage and its edition, change, and refresh boundary, plus any maintenance relation actually claimed; the full process adds software assets, features, roles, and mechanisms before the practical boundary is known. Adapt: E.4.PFAD:4.1–4.2 uses a cheap exit, same-grain alternatives, practitioner problems, receiving use, evidence limits, direct subjects, edition/change/refresh boundaries, any obtaining maintenance relation, consequences, and reopen; a material family change routes to E.4.DPF.DA. Reject: software feature ontology and a mandatory generic scoping process.Marchezan de Paula et al., Software product line scoping: A systematic literature review (2022), is a systematic synthesis with context and evaluation limits; it does not decide an FPF or DPF boundary, prove reuse value, or supply the E.9 decision. Current E.4, E.9, and E.4.DPF.DA retain those responsibilities.Reopen if stronger current scoping evidence changes the decision variables or a repeated case shows that the cheap-exit/full-decision split loses a necessary boundary.
    What evidence prevents a broad framework name or coherent pattern slice from masquerading as a validated domain contribution?Riehle, Harutyunyan, and Barcomb's 2025 validation line, bounded by Chuprina et al.'s 2024 domain-specific proof of concept, is the best-known current comparison for explicit cases, evidence limits, and actual-use pressure without claiming one universal field grammar.Pattern count, broad domain labels, and source-layout coherence are the serious defaults.These defaults make visible specificity substitute for action-changing contribution and warranted retention. Adapt: E.4.PFAD compares the same situation at comparable effort, names representative cases and limits, keeps external-result use honest, and separates distinct contribution from package coverage; reject a universal grammar and a research programme at the cheap exit.Riehle, Harutyunyan, and Barcomb, Pattern Discovery and Validation Using Scientific Research Methods (2025), supplies the validation branch. Chuprina et al., Towards an Approach to Pattern-based Domain-Specific Requirements Engineering (2024), supplies bounded proof-of-concept evidence; transfer beyond its evaluated setting remains untested.Reopen if stronger current pattern-validation or domain-pattern evidence changes the same-situation action test, the evidence limit, or the family-coverage trigger.

    The two comparison rows above are the selected external sources. The E.9 DRR shape and neighboring FPF boundaries remain direct internal rules.

    Relations

    • Uses: E.9 to record the one bounded answer selected by the decision-maker during decision Work.

    • Uses: E.4, E.4.DPF, and E.4.DPF.DA for framework scale, authoring, field coverage, and package assurance; uses E.4:4.2 when one decision selects a DPF Suite and E.11.DSG when that Suite has a separately constituted DPF Suite Reference product series.

    • Uses: C.32.MWA when several practice structures need one readable synthesis; uses E.23.CDI only when capability development for a named Work family changes the answer.

    • Uses: A.6.RCD, A.6.REL, and the exact relation patterns for material relation assertions among initial patterns.

    • Coordinates with: A.22, C.30.STRAT, B.1.5, A.15.1, C.30.AD, and C.36 for selected structures and exact architecture distinctions.

    • Coordinates with: E.4.PFR for optional relation and edition maintenance representations.

    • Coordinates with: C.32.PAD for an exact project architecture decision, C.32.ADR for its ADR-like projection, and E.17 with E.24.PUB for publication of an ordinary framework answer.

    • Coordinates with: F.18, G.2, G.11, E.21, E.23, and E.19 only when naming, source synthesis, refresh, improvement, or admission is current for the selected answer.

    E.4.PFAD:End

    Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)