#FPF Ecosystem Family Architecture

E.4 · 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 FPF user, framework author, or steward needs to create, extend, or use an FPF-grounded pattern ecosystem and must know what belongs to FPF itself, what belongs to the FPF Core, what belongs to a domain or local framework, which records carry relation and edition claims, and which neighboring patterns contain the defining content for publication, access, naming, source, currentness, and quality work.

#Relations

#Content

#Problem frame

Use this pattern when an FPF user, framework author, or steward needs to create, extend, or use an FPF-grounded pattern ecosystem and must know what belongs to FPF itself, what belongs to the FPF Core, what belongs to a domain or local framework, which records carry relation and edition claims, and which neighboring patterns contain the defining content for publication, access, naming, source, currentness, and quality work.

Primary EntityOfConcern: the FPF-grounded pattern ecosystem for one named ecosystem question. The first useful result is a direct route or honest stop: name the question, classify the likely case, and point to the next pattern. Open a complete ecosystem-architecture record only when the answer must settle durable architecture or support later reliance.

This pattern buys a practical distinction: a reader can tell whether a claim changes FPF itself as a first-principles framework edition, changes the FPF Core, creates a domain principle framework, creates a local practice framework, publishes or teaches existing content, exposes a skill-pack, index, or response carrier, or an MCP, retrieval, search, or assistant access route, or records a dependency on another framework edition. Use E.4.FPF when the work is the form of FPF itself; use E.11 and E.17 for first-entry and publication questions; use E.4.DPF when the work is to author a domain or local framework.

#Problem

FPF has grown from a single core pattern set into an ecosystem of core rules, tools, companions, domain frameworks, local practice frameworks, source packs, decisions, quality records, publication and access-facing presentation carriers, and access routes. If those objects are described only by file names, abbreviations, or reader-facing tables of contents, several different kinds collapse:

• a pattern set is treated as a publication or access carrier;
• a local practice framework is treated as an FPF Core amendment;
• a relation record is treated as a method order;
• a dependency on a framework edition is treated as a specialization relation;
• a source or generated carrier is treated as architecture evidence without source-return and preservation claims.

The result is a framework that may look organized but cannot answer ordinary architecture questions: what structure is selected, what depends on what, what can change independently, what is preserved by a projection, and which stronger claim requires another pattern before it is used.

#Forces

#Solution

Describe an FPF-grounded pattern ecosystem as a family of framework editions and publication and access-facing presentation carriers, plus access routes, over selected structures. For each durable ecosystem-architecture claim, or technical claim on which later work will rely, state the exact subject and relation and cite the defining or constraining ClaimGraph in its subject pattern. The smallest route below needs no ClaimGraph citation when ordinary guidance or an honest stop already answers the question. A principle framework edition is not merely a bundle of documents, an ontology catalogue, a literature survey, or a guide to talking about a domain. Its pattern language renders a selected architecture of recurring problem situations, forces, known failure modes, reusable SoTA solution moves, consequences, cases, relation records, evaluation methods, and refresh conditions for a declared reader and use. Known failure modes include beginner mistakes and experienced-practitioner failures caused by stale, local-only, or non-SoTA practice.

Start with the smallest route that answers the current question:

1. Name the concrete ecosystem question and who needs the answer.
2. Classify the likely case: a framework-family boundary, an adjacent maintained result, a publication carrier, access-facing presentation carrier, or access route, a DPF-suite question, or another relation already handled by a direct pattern.
3. Point to that direct pattern and state the next useful move, or stop with the exact missing distinction.
4. Open the complete ecosystem-architecture record only when the answer must persist as ecosystem architecture or later work must rely on the selected structures and relations.

This route is ordinary guidance, not a new record or package. A direct pattern or honest stop is a complete first result when no durable ecosystem-architecture record is needed.

Create an ecosystem-architecture record only when that durable architecture or later reliance is current. Use these fields:

FPFEcosystemArchitectureRecord@Context:
  ecosystemScopeRef
  intendedArchitectureUse
  claimScopeRef?
  sourceRefs?
  patternHostRefs?
  selectedArchitectureStructureRefs?
  publicationRelationRefs?
  boundedModelUseStructureRef?
  frameworkFamilyMembers
  selectedPatternSetRefs
  selectedProblemSituationStructureRefs
  selectedKnownFailureModeRefs
  selectedSoTASolutionMoveRefs
  selectedSolutionMoveStructureRefs
  selectedRelationRecordRefs
  frameworkCarrierRenderingRefs
  selectedDependencyAndEditionRefs
  selectedPublicationOrAccessCarrierRefs
  selectedSourcePackRefs
  selectedDecisionRefs
  qualityAndImprovementRefs
  currentnessAndRefreshRefs
  blockedOverreadRefs
  dependentUsePatternLocators

This record answers the declared ecosystem question for its intended use. It is not a new root kind, a source of semantic locality, or a substitute for the subject claims and patterns it cites.

Classify the family members as follows:

Conceptual Core is the legacy authority and publication-family partition. First Principles Framework edition is the whole scoped FPF framework edition as a transdisciplinary first-principles framework. FPF Core pattern set is the framework-edition view of the general FPF Core used for dependency, relation, and edition reasoning. These are related views and scopes, not competing core objects.

#Place support units and adjacent products deliberately

In this pattern, product is Plain management wording for a deliberately maintained result or service boundary. It is useful because it makes a team decide intended use, identity or current state, access, maintenance, refresh, and retirement together. It is not one FPF technical kind and it creates no U.Product. Before making a product-boundary claim, name the direct subject—the thing the claim is about—and the relation that carries its identity, edition, current state, provision, or maintenance. The subject may be, for example, a framework-edition episteme, an evidence-package episteme, an admitted System, an admitted service arrangement, a Method, a programme-description episteme, or another result already admitted by its subject pattern. If the direct kind or relation is not settled, keep the management boundary as a proposal and return that exact question instead of inventing a common object kind.

A framework edition is an exact episteme. Treat its Readme, Preface, table of contents, pattern-body collection, framework-scale structure or coverage account, relation or edition note, and refresh route as named publication units in the same managed boundary when they share the edition's declared readers and use, edition boundary, access, maintainer, and change cadence. Being outside the pattern set or in another file does not by itself create another maintained result.

Make a separate adjacent product only when people need to change, cite, use, or maintain its direct subject independently. Look for an independently useful identity, edition or current state, named users and use, an intensional rule for what belongs, access, a maintenance commitment, a refresh or retirement rule, or cross-framework reuse or reliance. For example, a registry, MethodDescription collection, decision-support publication, inquiry evidence package, practitioner guide, pedagogical companion, catalogue, tool reference, access service, or inquiry programme may justify a separate boundary. The label does not settle the kind: a guide or evidence package may be an editioned episteme; a tool reference may identify an episteme, a tool System, or both; and an access service needs its own service and provider-System claims. The list is open, and file location does not decide the boundary.

When the direct subject is independently maintained, keep it separate and point from the framework to its exact edition or current state. An annex may carry a declared snapshot or projection, but it returns to the authoritative subject and does not fork it. When no independent boundary is useful and ordinary framework use needs the material, keep it as a named support publication unit of the framework edition.

One presentation carrier may expose several managed products without merging their direct subjects. Each constituent keeps its own identity, edition or state, form, access, maintainer, and refresh relation; the outer navigation names exact constituents and stays neutral. A result reused by several DPFs may therefore be managed as an ecosystem companion or service product. Shared use does not make it a parent DPF. Open another DPF only when its own field-boundary assessment finds recurring practitioner problems, constructive Methods, an independently useful first cut, evidence practice, and a maintenance boundary.

When programme is used, start with what actually continues. An inquiry programme may be managed as a continuing programme or service product, but neither label says what persists. If a subject pattern admits the programme as a System or another exact arrangement, name it. Otherwise name the current programme-description episteme, capable provider and maintaining Systems with their accepted commitments, and any admitted service state. Bounded inquiry projects remain separate Work occurrences, and their results remain separate epistemes. A maintained inquiry evidence package is its own editioned episteme. The management boundary may coordinate these subjects and relations, but it does not turn them into one indefinitely continuing U.Work or one generic Product. If the persisting arrangement is still unclear, return that exact architecture question.

DRRs, build manifests, quality runs, digests, logs, and campaign state remain maintainer or process evidence by default. They become reader products only when a separately selected public use gives a direct subject its own maintained boundary.

Use these tests in order: name the intended managed boundary and ordinary use; identify every direct subject, its kind, and the identity or current-state relation used by the decision; group only publication units that share the framework edition, readers, access, maintainer, and cadence; test a proposed adjacent subject for independent use and maintenance; select the smallest useful boundary; then record exact pointers, snapshot return, and neutral-carrier navigation. If a needed kind or relation remains unresolved, record that question and stop short of the technical product claim.

#Keep several DPF products usable as one suite

Use this branch when independently maintained DPF products contribute to one ecosystem and people need to recover which product series belong to the Suite and how to use them while each product changes on its own. Keep distinct each continuing DPF product series, any separately constituted DPF Suite Reference product series, the continuing DPF Suite collection, and any as-of description of that collection. This introduces no U.Product, U.DPFSuite, or U.DPFSuiteReference kind.

Here DPF product series is Plain relation-defined wording for a continuing collection of a DPF's edition epistemes. The series begins only when a product-constitution decision names at least one existing edition, intended readers and use, content-selection and edition-admission rule, access, refresh and retirement conditions, reidentification rule, and a capable maintaining System whose maintenance commitment has been accepted. The decision's effect begins the collection and admits the first edition; its Work and record are not the product series or the belongs-to occurrence.

Say “this edition belongs to this product series.” A later edition joins only when its EpistemeEditionRelation to the actual source edition obtains, the product-series rule still holds, and an admission decision takes effect. The edition relation establishes episteme continuity but does not admit the edition to the product series. A parallel branch, fork, translation, or derivative joins only when both its source relation and the admission rule pass. Otherwise it remains a related episteme outside the series or begins another product series. The series need not be one total version order.

An admitted edition continues to belong historically when it becomes superseded, unavailable, non-current, or retired while the same product series continues. Those states do not end the occurrence. If the product series ends or its identity rule identifies another product series, belonging to the old series ends and remains a past fact. Another product series must admit the edition through its own decision and a new occurrence. If review shows that the edition never satisfied the admission rule, correct the false claim; no valid occurrence existed. Do not remove and re-admit the same edition merely because availability or currentness changed. The same edition and continuing product series keep one occurrence rather than starting another.

A DPF Suite is a continuing collection of DPF product series. A separately constituted DPF Suite Reference product series can also belong after its own inclusion decision. The Suite rule states which product series may belong; individual editions do not. The Suite begins when a constitution decision identifies the ecosystem purpose and intended use, inclusion and removal rules, reidentification rule, maintenance conditions, and a capable maintaining System whose Suite-maintenance commitment has been accepted, and includes at least one actual DPF product series. The decision Work and record remain distinct from the Suite and the first inclusion occurrence.

The same Suite continues while its ecosystem purpose, rule for which product series may belong, inclusion and removal rules, and maintenance and identity conditions remain within the declared evolution rule. Adding or removing a product series normally preserves it, as can an explicit maintenance transfer that preserves those conditions. Changing a DPF or Reference edition, publication, availability fact, Reference answer, or configuration description does not by itself reidentify the Suite. Changing an identity anchor outside the rule identifies another Suite.

After constitution, a temporary one-product-series or empty state can preserve the same Suite only when an explicit decision keeps those anchors in force and names a restoration, review, or retirement condition. Present no current cross-DPF answer in that state. An end or retirement decision closes the continuing collection and ends every current belongs-to occurrence; separate removals are unnecessary. The Suite and the past facts remain identifiable, but later active use requires another constitution decision, another Suite, and new inclusions. Before constitution there is only a possible-future Suite.

Say “this product series belongs to this DPF Suite.” The relation begins when the product series satisfies the operative inclusion rule and an inclusion decision takes effect. It remains current while the same product series and Suite continue and no later removal decision has taken effect. While they continue, only an effective inclusion or removal changes that occurrence. If either collection ends, or its identity rule identifies another collection, belonging to the old collection ends; neither case requires a prior removal. A proposal, description, publication, locator, or common use may report the relation but does not make it obtain.

Loss of qualification does not silently change belonging. Show an action-changing warning and decide whether to repair qualification, remove the product series, change the Suite under its identity rule, or retire it. Until that decision, do not present the product series as qualifying, current for the defeated common use, or recommended on that basis. Restoration before removal keeps the same occurrence while the same product series and Suite continue. An effective removal ends it; a later inclusion begins another occurrence.

After an occurrence ends, say that the product belonged to the Suite and say when it ended; do not present past belonging as current. A reconstituted product series or Suite, or one reidentified under its rule, is another collection and needs a new inclusion decision and occurrence.

Belonging alone establishes neither parthood nor holonhood, and it does not make either impossible. The current product-series and Suite definitions leave A.1 matters 3, 5, and 6 unsettled: no constructive part relation and assembly, composition-grounded whole characteristic, or possible participation in a larger constructive assembly is currently established. Treat both as continuing collections without a present holon or parthood claim. If a later complete A.1 result and direct part predicate pass, state that additional claim separately. Belonging also settles no relation about order, dependency, compatibility, recommendation, publication, availability, currentness, maintenance, or use in an answer. One product series may belong to several Suites. Use the direct sentence without assurance fields unless the publication elects B.3.5; after election, use its validationMode=axiomatic and current C.13 set-trace obligations without treating the trace as the cause.

A DPF Suite Reference product series belongs to the Suite only after its own inclusion decision and keeps its own reader use and maintenance conditions. It may join after the first DPF products; it did not belong beforehand. Its absence, unavailability, staleness, or non-use does not erase the Suite or block direct use of a known DPF result. Those conditions only prevent a claim that the Reference currently supplies a trustworthy cross-DPF route.

For a reproducible as-of answer, use an optional DPF Suite configuration description: a U.Episteme about the Suite, the product series that belong at that time or in that scope, selected editions or states, and direct source return. Its own editions are description editions, never Suite editions. It describes neither the belongs-to occurrences into existence nor the Suite's identity.

Use G.5 JointUseSet only when every identified result or edition is necessary for one bounded use. A question may need resources from only some product series in the Suite. The set therefore neither defines Suite identity nor implies that every product is used together.

Present the Suite as currently maintained only while a capable System holds its Suite-maintenance commitment and readers can return to the collection identity, inclusion and removal decisions, and any product-series state claimed as current. A neutral carrier or a current DPF Suite Reference edition may expose those returns, and an optional configuration description may pin them. None merges the Suite, Reference product series, Reference edition, DPF product series, DPF edition, carrier, access, maintenance, or currentness. Apply E.17, E.24.PUB, C.2.P, and G.11 to their direct claims; use E.4.PFR only for a dependency or compatibility relation that separately obtains; and use E.11.DSG for the Reference's problem-led route and direct-DPF bypass. The ordinary method is:

1. Declare the ecosystem scope and intended architecture use. Cite the exact source, pattern host, selected architecture structure, publication relation, or bounded model-use structure only when the record actually relies on it.
2. Name the family member being created, used, or changed.
3. List the selected structures that matter for the architecture claim: recurring problem-situation structures, known failure modes, reusable SoTA solution-move structures, pattern set, pattern-use relations, pattern-framework relations, decision records, dependency and edition records, publication and access-facing presentation carriers, access routes, source packs, quality records, and currentness records. For PF work, the pattern-language publication carrier exposes a reader-facing expression of that problem-and-solution architecture, not a neutral list of topics.
4. If the family member is FPF itself as a framework edition, open E.4.FPF for form, presentation carriers, access routes, and whole-FPF adequacy routing.
5. Apply E.5.3: dependencies point toward more stable framework editions. FPF Core does not depend on domain or local frameworks.
6. State publication and first-entry claims using E.11 and E.17; state framework-carrier structure-account assertions using E.4.FPF for FPF itself or E.4.DPF/E.4.DPF.DA for domain and local frameworks.
7. State pattern-use recommendation claims using E.11.PUR.
8. When a framework-architecture question is open, record the selected answer in one E.9 DRR and use E.4.PFAD to profile its framework-specific content. Use C.32.PAD only for an exact project architecture decision and C.32.ADR only to project such a decision into an ADR-like publication.
9. State relation, dependency, compatibility, deprecation, and edition claims using E.4.PFR only when its named maintenance use requires that representation; otherwise use the direct subject assertion.
10. Settle names using F.18.
11. State SoTA and source-use claims using G.2.
12. State currentness, refresh, and edition-change claims using G.11, the exact edition values, and their source/currentness assertions.
13. Before using an all-in-one carrier, table of contents, relation graph, summary, skill pack, MCP-backed service, or generated carrier as evidence, state the exact source-return or preservation assertion under the predicate defined in C.33, C.34, or C.35.
14. Evaluate whole-FPF adequacy through E.2.DA, DPF or local-framework package adequacy through E.4.DPF.DA, individual pattern quality through E.21, improve through E.23, and use E.19 only when the local process asks for admission review.

Use this routing table when a proposed change is ambiguous:

This pattern should leave the reader with one architecture sentence: "This framework edition belongs to this family member, expresses this selected architecture of recurring problems and solution moves in pattern-language form, depends on these stable editions, publishes or gives access through these carriers, preserves these selected structures, and states each neighboring claim under its exact predicate or constraint with the subject pattern available as a locator."

#Archetypal Grounding

Tell: A team creating a hydroponic-cucumber domain principle framework should not place every useful crop-growing rule into FPF-Spec.md. It creates a domain framework edition grounded in FPF Core and horticulture SoTA, declares its dependency on an FPF Core edition, records its source packs, drafts domain patterns under E.8, and publishes an all-in-one publication carrier for growers or agronomists.

Mini-example:

Show: A Codex-process local practice framework may depend on FPF Core and selected architecture-domain patterns. Its handoff patterns, prelanding patterns, and process runbooks can be local framework material. They do not define the FPF Core merely because they use FPF vocabulary and are useful to this workspace.

Show: A generated relation graph over pattern names can help inspect missing relation records. It becomes architecture input only after C.35 admits the carrier and E.4.PFR records the relation functions. The graph's shape alone is not the ecosystem architecture.

Show: In the cucumber DPF, the Readme, table of contents, pattern collection, and coverage account share one framework edition, reader use, access route, maintainer, and cadence, so they remain publication units in one managed boundary. A greenhouse-calibration source registry is revised separately and reused by another crop DPF, so its current registry edition is a separate episteme. One web carrier may expose both, but its links neither merge their identities nor create a generic Product relation.

#Bias-Annotation

Scope: limited. This pattern helps make architecture claims about FPF-grounded framework ecosystems and their maintained publication, access, companion, and service boundaries. It does not supply a universal product taxonomy, a service-design Method, a programme ontology, or a complete content-management system.

The recurrent drift is publication-first architecture: the visible file, all-in-one carrier, card deck, table of contents, or graph is treated as the architecture because it is what a reader sees first. The repair is to name the selected structures and dependency direction first, then use publication patterns to expose them.

Another recurrent drift is Core absorption: useful domain or local material is pulled into the Core because it is well written or broadly reusable. The repair is to ask which domain or local situation the claim addresses and which framework edition should depend on which more stable edition.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

This pattern makes FPF ecosystem work slower at the beginning because a framework author must name family membership, dependency direction, selected structures, and the patterns needed for neighbouring claims. The gain is that later work can evolve without hidden Core changes, hidden publication substitutions, or hidden source loss.

It also makes some attractive names and short labels provisional until F.18 settles them. That cost is intentional: short names are useful only after the value being named, its source-local meaning, and its intended use are explicit.

#Rationale

The ecosystem needs architecture because FPF patterns, frameworks, source packs, exact presentation carriers, access routes, quality records, and decisions are not one kind of object. A file tree cannot preserve the differences among those objects. A relation graph cannot preserve decision rationale or dependency compatibility. An all-in-one publication carrier, callable access route, or returned access-facing carrier cannot preserve all source-return and currentness obligations by itself. Architecture work must therefore name the selected structures and apply the relevant pattern to claims outside this pattern's scope.

The old Core, Tooling Reference, and Pedagogical Companion distinction remains valuable, but it is only one family partition. Domain and local principle frameworks need their own framework editions so they can depend on Core without redefining it.

#SoTA-Echoing

Official catalogues, vocabulary standards, current release pages, tool documentation, lineage sources, and source-maintenance checks may identify a source or explicit default elsewhere. None appears here merely to make the architecture look current, and none can establish product kind, service kind, publication identity, relation truth, or SoTA rank.

#Relations

• Builds on: E.2/P-5 FPF Layering and E.5.3 for modular extension, directed dependency, and family-order discipline.
• Coordinates with: E.4.FPF when the work concerns FPF itself as a first-principles framework edition, its presentation carriers, access routes, and whole-FPF adequacy route.
• Coordinates with: E.2.DA when the scoped FPF object needs whole-FPF Pillar adequacy evaluation.
• Coordinates with: E.4.PFAD when the ecosystem-architecture record opens a framework-architecture question; E.4.PFAD profiles the framework-specific content, E.9 supplies the decision-record method and content requirements, and the resulting DRR records the selected answer.
• Coordinates with: E.4.DPF when the work is to author a domain principle framework or local practice framework.
• Coordinates with: E.4.PFR when a relation, edition, dependency, compatibility, deprecation, or preservation claim must be recorded.
• Coordinates with: E.4.DPF.DA when a domain or local framework package must be evaluated as a package rather than as an average of its pattern bodies.
• Coordinates with: E.11 for discoverability, E.11.PFP for the common publication form of FPF, DPF, or LPF constituents, E.11.DSG for the separately maintained DPF Suite Reference product series and its reader-facing cross-DPF answers, E.11.PUR for pattern-use recommendation, E.17 for a source-backed publication face and return to source, and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability.
• Coordinates with: G.2, G.11, C.33, C.34, and C.35 for source, currentness, preservation, and produced-carrier admission claims.

#E.4:End

Last Updated: 2026-08-30 — upstream FPF commit e400eab3 (github.com/ailev/FPF)