#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 maintained product that is not a framework, a thinner publication or access route, and no new maintained product, and that choice will settle a boundary that later work must use. The boundary may concern the public field and first use, framework edition, dependencies, initial pattern placement or relations, the kind and maintenance boundary 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

#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 maintained product that is not a framework, a thinner publication or access route, and no new maintained product, and that choice will settle a boundary that later work must use. The boundary may concern the public field and first use, framework edition, dependencies, initial pattern placement or relations, the kind and maintenance boundary 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.

Here product has the Plain management meaning declared in E.4:4.1; it is not a technical kind. When a maintained non-framework alternative is selected, the answer names the direct subject—the thing being maintained—its kind, and the relations used for identity, current state, provision, and maintenance. 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. Do not open a framework-architecture DRR merely because E.4.PFAD exists.

When the architecture question is live, use E.4.PFAD to state the framework-specific content of one ordinary E.9 DRR. Decision Work selects the answer; the DRR records it. This pattern is a practitioner-facing profile and locator. No PFAD relation or second decision record is created, and acceptance remains separate.

#Problem

Framework authors repeatedly need to decide whether a recurring practitioner problem calls for a new framework, an existing framework contribution, another maintained product such as a programme, service, or evidence package, a thinner access result, or no maintained product. 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

#Solution

#Decide whether the architecture question is open

Ask whether choosing a framework, a maintained non-framework product, a thinner route, an existing-framework contribution, or stop will settle at least one boundary 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 maintenance boundary for a continuing programme, an admitted service, or a separate editioned result when later work must maintain or use them;
• 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, maintenance and source-return conditions, exposure choice, and any separate DPF Suite Reference product decision.

If no such boundary and receiving use are present, close the exploratory use without E.4.PFAD or an E.9 DRR. If they are present, decision Work selects a framework, maintained non-framework product, thinner route, existing-framework contribution, or stop and one E.9 DRR records that answer. The cheap exit and the architecture decision are alternative entry outcomes, not serial stages.

For every maintained 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. A quality-management, service-management, publication, or content-management scheme may supply a useful probe, but it does not settle the FPF kind. If the unresolved kind can change the selected boundary, keep the boundary 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 maintained non-framework product, a thinner publication or access route, or no new maintained product now; for a maintained non-framework product, also the direct subject kind and the identity, current-state, provision, or maintenance relations 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 an existing framework, selecting a programme or service boundary, selecting a separate evidence-package episteme, or keeping no maintained product; 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.

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 is content of that one answer and its one ordinary E.9 DRR, not a second architecture record, fixed schema, or later DPF invention. Fill each group only to the grain that changes first use:

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, non-use boundary, qualification window, and receiving decision.
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: state what current FPF and admitted DPFs already supply, each receiving pattern and domain filling still needed, exact external results, honest omissions and gaps, and the observation that reopens the architecture.

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 before DPF authoring; the DPF author does not invent the missing value. 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. Decision Work selects that answer. A separately identified authorized acceptance decision accepts, redirects, rejects, or reopens it; carrier identity, DRR identity, or the fact that authoring continued identifies neither the accepting decision nor acceptance. Only the exact accepted answer is handed to E.4.DPF.

Common practice questions include:

If another question changes the answer, name it and the pattern that handles it instead of forcing it into these rows. Do not infer Method parthood from a required contribution, transformation, performed Work, capability, provider contribution, or cultural change. 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. A current maintained-Suite claim also identifies the capable maintaining System and its accepted commitment, the working source return for product series and any product-series state presented as current, the refresh response, and one exposure choice: 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 and maintaining its editions, and refreshing their answers remain separate decisions and claims. A proposed result use or future constraint is not an obtaining dependency or compatibility relation; apply E.4.PFR only after the edition-level case facts exist.

For an existing-framework contribution, maintained non-framework product, thinner route, or stop, state only the parts needed to explain that outcome and the later-used boundary. A selected maintained product still names its direct subjects and the relations used; a proposed boundary with an unresolved kind says so. Do not fabricate a field assessment or package merely to fill the list.

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. A narrower label or example is not a difference. A difference that adds an unsupported or needless burden is not worth preserving merely because it changes action.

When the answer treats a promised problem family as covered by a result maintained outside the framework, name the exact result, its direct kind, supplying product and 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. 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. A matching current result remains usable when that edition and its exact basis are unchanged; the architecture answer does not ask D12 to prove 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. Use the pattern that defines, constrains, or tests each added claim; do not make it a standing PFAD field.

#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.

An optional E.4.PFR row may later represent these assertions for maintenance. The row neither makes the relations obtain nor becomes mandatory for the architecture answer. A generic relation catalogue is not a prerequisite for the decision.

#Keep the answer, DRR, authoring, and publication distinct

Decision Work selects the answer. The E.9 DRR records that answer and its rationale. An authorized acceptance decision accepts, redirects, rejects, or reopens it. Later authoring follows an accepted answer. A framework edition is the maintained pattern-language result assembled from accepted sources, not the DRR or the authoring Work. An ADR-like document, site, PDF, or other carrier publishes or projects claims about these things; its form creates none of them.

When the answer uses C.32.MWA or E.23.CDI, keep each proposed Method distinct from the pattern that describes it, the Work that performs it, the result of that Work, the framework answer, the DRR, and the resulting edition. A proposal or evidence locator may help a reader find supporting material; it is none of those things.

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 independently maintained DPF edition series, and no maintained product. It favors one DPF because a representative service-launch case needs patterns from several problem-family sets together and has an independent refresh boundary.

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 without turning the source layout into 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. E.23.CDI is absent because capability development does not change this answer. No PFAD relation, mandatory PFR row, or proposal locator substitutes for the selected answer.

#Exploratory access result

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

#Decision-level access result

A team needs a maintained choice among a DPF, an access route, and stop because later work depends on the rationale. The architecture question is therefore open. One E.9 DRR selects no new framework edition, states the maintained access consequence and stop, and records when to reconsider 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, a maintained inquiry-programme boundary, a separate inquiry evidence-package episteme, a curated route, and no maintained product. It selects the programme boundary because named users need continuing access to inquiry Methods, bounded-project intake, and result return. The answer does not invent a Programme or Product kind.

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. Capable provider and maintaining Systems accept the needed commitments; when a service is claimed, the answer also names the admitted service state. Each bounded inquiry project is separate Work, 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 independently maintained DPF product series already cover one recurring practitioner use. The architecture question is therefore not whether to merge them into another DPF. 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, identifies the capable maintaining System and its accepted Suite-maintenance commitment, 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, identifies its capable maintaining System and commitment, and states its refresh route. A Reference edition may then give a problem-led cross-DPF answer, but it neither constitutes the Suite nor decides which product series belong. The answer records any proposed cross-DPF result use but makes no dependency or compatibility claim until the edition-level predicates pass. A later author may propose inclusion or removal, but returns that proposal to the Suite decision; one DPF and one Reference edition cannot settle it from inside their own content.

#Existing framework

A local practice framework already has an accepted architecture answer and a source record. Changing an example or publication carrier creates no new PFAD stage. Reopen only when its selected edition boundary, dependencies, initial pattern architecture, or publication or access consequence changes.

#Bias-Annotation

Scope: limited. This profile decides a later-used architecture boundary for an FPF-grounded framework, maintained 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.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#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 prevents a broad title, small authoring slice, source layout, or proposal locator from silently becoming a public pattern language. Conditional naming, package, quality, and machine-readable detail stays out until a named use needs it.

#Rationale

Framework authors need a recurring set of framework-specific questions, so removing every PFAD locator would make the entry harder to discover. They do not need a separate PFAD relation or record: E.9 already carries one bounded answer, alternatives, rationale, consequences, action, and reopen condition.

The field-boundary assessment prevents a coherent slice from acquiring a field-scale identity without the practitioner coverage and independent use that justify it. The several-structure branch prevents one source layout from standing in for the practice architecture. Direct assertions preserve selected initial pattern relations without making their representation authoritative.

PFAD is therefore a profile by practical question and content, not a new ontological kind or a second stage.

#SoTA-Echoing

Compact ADR practice, official standards, current catalogue entries, publication-form vocabularies, and maintained template pages are not retained here as a mixed source shelf. The E.9 DRR shape and neighboring FPF boundaries remain direct internal rules; their currentness cannot substitute for the two best-known comparisons above.

#Relations

• Uses: E.9 for the one bounded answer selected by decision Work and recorded in the DRR.
• 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 maintained DPF Suite and E.11.DSG when that Suite has a separately maintained 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-08-30 — upstream FPF commit e400eab3 (github.com/ailev/FPF)