#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 own 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 own publication, access, naming, source, currentness, and quality work.

Primary EntityOfConcern: the FPF-grounded pattern ecosystem in one bounded context. The first useful output is a family-and-structure map that names the framework family members, selected architecture-relevant structures, recurring problem-situation structures, reusable solution-move structures, dependency direction, edition boundary, publication/access carriers, and receiving owners for source, currentness, quality, and decision claims.

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 or MCP access carrier, 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 carriers, and access carriers. 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 what must return to a stronger owner before it is used.

#Forces

#Solution

Describe an FPF-grounded pattern ecosystem as a family of framework editions and publication/access carriers over selected structures, then route each claim to the pattern that owns that kind of work. 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 routes, and refresh paths 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.

Create a family-and-structure map with these fields:

FPFFamilyAndStructureMap@Context:
  ecosystemScopeRef
  boundedContextRef
  frameworkFamilyMembers
  selectedPatternSetRefs
  selectedProblemSituationStructureRefs
  selectedKnownFailureModeRefs
  selectedSoTASolutionMoveRefs
  selectedSolutionMoveStructureRefs
  selectedRelationRecordRefs
  frameworkCarrierRenderingRefs
  selectedDependencyAndEditionRefs
  selectedPublicationOrAccessCarrierRefs
  selectedSourcePackRefs
  selectedDecisionRefs
  qualityAndImprovementRefs
  currentnessAndRefreshRefs
  blockedOverreadRefs
  receivingPatternRefs

This map is a context record. It is not a new root kind and not a substitute for the patterns that own the referenced claims.

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.

The ordinary method is:

1. Declare the ecosystem scope and bounded context.
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/access carriers, 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](/generated/patterns/E.4.FPF) for form, publication/access carriers, and whole-FPF adequacy routing.
5. Apply [E.5.3](/generated/patterns/E.5.3): dependencies point toward more stable framework editions. FPF Core does not depend on domain or local frameworks.
6. Send publication and first-entry claims to [E.11](/generated/patterns/E.11) and [E.17](/generated/patterns/E.17), and send framework-carrier structure-account questions to [E.4.FPF](/generated/patterns/E.4.FPF) for FPF itself or [E.4.DPF](/generated/patterns/E.4.DPF)/[E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) for domain and local frameworks.
7. Send pattern-use recommendation claims to [E.11.PUR](/generated/patterns/E.11.PUR).
8. Send architecture-decision claims for a framework to [E.4.PFAD](/generated/patterns/E.4.PFAD), and general project architecture decisions to [C.32.PAD](/generated/patterns/C.32.PAD).
9. Send relation, dependency, compatibility, deprecation, and edition claims to [E.4.PFR](/generated/patterns/E.4.PFR).
10. Send naming settlement to [F.18](/generated/patterns/F.18).
11. Send SoTA and source-pack claims to [G.2](/generated/patterns/G.2).
12. Send currentness, refresh, and edition-change claims to [G.11](/generated/patterns/G.11) and the edition owners.
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 source-return or preservation through [C.33](/generated/patterns/C.33), [C.34](/generated/patterns/C.34), or [C.35](/generated/patterns/C.35).
14. Evaluate whole-FPF adequacy through [E.2.DA](/generated/patterns/E.2.DA), DPF or local-framework package adequacy through [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA), individual pattern quality through [E.21](/generated/patterns/E.21), improve through [E.23](/generated/patterns/E.23), and use [E.19](/generated/patterns/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 sends each non-owned claim to this receiving pattern."

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

#Bias-Annotation

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 bounded context owns the claim 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 receiving owners. 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 governed value and bounded context are stable.

#Rationale

The ecosystem needs architecture because FPF patterns, frameworks, source packs, publication carriers, access carriers, 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 or callable access carrier cannot preserve all source-return and currentness obligations by itself. Architecture work must therefore name the selected structures and route non-owned claims to their owners.

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

#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 publication/access carriers, 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 family-and-structure map requires an architecture decision about a framework edition.
• 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, E.11.PUR, and E.17 for publication, discoverability, and pattern-use recommendation claims.
• 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-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)