E.4:4.2 - Keep several DPF products usable as one suite

Use this branch when separately constituted DPF product series contribute to one ecosystem and people need to recover which product series belong to the Suite and how to use their current or historical editions. 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 when a product-constitution decision names at least one existing edition, intended readers and use, a content-selection and edition-admission rule, a reidentification rule, and later-review and retirement conditions. The decision’s effect begins the collection and admits the first edition. A separate publication occurrence may make that edition available. A maintaining System, maintenance commitment, revision duty, another edition, or continued availability requires a separate claim. The decision 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 belong directly to the Suite. The Suite begins when a constitution decision identifies the ecosystem purpose and intended use, inclusion and removal rules, a reidentification rule, later-review and retirement conditions, and includes at least one actual DPF product series. Any maintenance relation or future maintenance Work must be established separately. 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 identity conditions remain within the declared evolution rule. Adding or removing a product series normally preserves it. Starting, changing, transferring, or ending a maintenance arrangement does not by itself reidentify the Suite. 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 establishes collection membership between the product series and Suite. Apply A.1 before asserting parthood or holonhood: the current definitions leave matters 3, 5, and 6—constructive parthood and assembly, a composition-grounded whole characteristic, and possible participation in a larger constructive assembly—unsettled. Treat both as continuing collections; a later complete A.1 result and direct part predicate can add a constructive part or holon claim. State order, dependency, compatibility, recommendation, publication, availability, currentness, maintenance, and use through their own direct predicates. 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, admission, reidentification, later-review, and retirement conditions. Any maintenance relation remains separate. The Reference may join after the first DPF products. While its current availability and source return support the claim, it can supply a trustworthy cross-DPF route. Suite identity and direct use of a known DPF result rest on their own grounds.

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. Constitution and inclusion decisions establish Suite identity and belongs-to occurrences.

Use G.5 JointUseSet only when every identified result or edition is necessary for one bounded use. It represents that jointly necessary subset; another question may need resources from only some product series in the Suite. Suite constitution and inclusion remain the grounds for identity and membership.

Present the Suite as current or available only while its direct currentness and availability facts support that statement and readers can return to the collection identity, inclusion and removal decisions, and any product-series state claimed as current. Present it as maintained only when a separate maintenance relation and its current evidence support that stronger statement. A neutral carrier, current DPF Suite Reference edition, or optional configuration description may expose or pin those returns while preserving the distinct identities and relations of the Suite, product series, editions, carrier, access, maintenance, and 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:

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.
Name the family member being created, used, or changed.
Name only the fields from FPFEcosystemArchitectureRecord@Context that this architecture claim actually uses. For PF work, the pattern-language publication carrier exposes a reader-facing expression of the selected problem-and-solution architecture.
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.
Apply E.5.3: dependencies point toward more stable framework editions. FPF Core does not depend on domain or local frameworks.
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.
State pattern-use recommendation claims using E.11.PUR.
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.
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.
Settle names using F.18.
State SoTA and source-use claims using G.2.
State currentness, refresh, and edition-change claims using G.11, the exact edition values, and their source/currentness assertions.
Before using a carrier or transformed or generated view as evidence, state the exact source-return or preservation assertion under the predicate defined in C.33, C.34, or C.35.
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. Its rows are common routes, not a closed taxonomy:

Proposed work	Route to	Decision boundary
The form of FPF itself changes: README, Preface, ToC, monolith, host set, skill pack, MCP-backed access, or whole-FPF publication/access route.	`E.4.FPF`, with `E.2.DA` for whole-FPF adequacy; state relation or edition claims directly and open `E.4.PFR` only for its named maintenance consumer.	FPF uses the whole-FPF route, `E.4.DPF.DA` remains the package route for domain or local frameworks, and the carrier exposes the framework edition as a separate subject.
Accepted changes are being assembled into an FPF, DPF, or LPF publication, or continuity with a predecessor publication is claimed.	`E.4.PFIP` for the accepted-source and predecessor-preservation comparisons.	Require both PFIP conclusions when both claims are made. Source parity, build success, carrier continuity, and package adequacy answer narrower questions.
A distinction or rule is intended to constrain ordinary FPF use across many domains and downstream frameworks depend on it.	An accepted FPF Core amendment decision under `E.9`, followed by the exact subject patterns whose assertions change.	Core admission requires the transdomain constraint and accepted amendment decision; local and domain guidance stays in its direct framework edition.
A reusable principle supports FPF-grounded work but is not a general Core rule for all domains.	Give the foundational principle pattern set or other named framework edition its own identity; state its dependency directly and open `E.4.PFR` only for its named maintenance consumer.	The framework edition and dependency boundary stay visible outside the Core table of contents.
A source tradition or professional domain needs FPF-shaped patterns.	Domain principle framework through `E.4.DPF`, `G.2`, and `E.4.PFAD`; state dependencies directly and open `E.4.PFR` only for its named maintenance consumer.	The framework adds recurring domain problems, SoTA solution moves, cases, and use conditions to its source account.
One bounded local practice setting—for example a project, organization, workflow, tool, practitioner position, or audience—needs guidance.	Local practice framework through `E.4.DPF`; keep local source, publication, quality, and refresh records, and state separately any direct relation used for maintenance, responsibility, authority, assignment, or contact. If a load-bearing owner label has no current direct relation, return `missing-governor` instead of inventing one.	The named local setting bounds the guidance; a general FPF rule requires its own Core-amendment grounds.
Material needed for ordinary framework use shares the framework edition, readers, access, and change rule.	Keep it as a named support publication unit of that framework edition and expose it through the edition’s carrier route.	Another managed product needs an independent use or change rule.
A registry, guide, evidence package, service, programme, or other result has an independently useful identity or state, users and use, content rule, access, or later-review and retirement rule.	Name its direct subject and the relevant relation, keep it as a separate product, and point to its exact edition or current state; any embedded snapshot returns to that source. State maintenance only when it separately obtains.	Keep direct subjects separate under shared use, co-location, or one outer carrier; an unresolved kind remains a proposed product and an open question.
One carrier exposes several managed products.	Keep the outer carrier neutral and retain each direct subject’s form, identity, access, change rule, and any separately established maintenance relation. Use `E.11.PFP` only for FPF, DPF, or LPF constituents.	The neutral carrier exposes the exact direct subjects; framework-family fields apply only to framework constituents.
Several DPF product series and a DPF Suite Reference product series are proposed for one ecosystem.	Use `E.4:4.2` to decide product-series and Suite constitution, which editions belong to which product series, which product series belong to the Suite, identity through change, later review and retirement, optional configuration description, and truthful exposure; state maintenance separately only when it obtains. Use `E.4.PFAD` when the answer must be selected.	Constitution and inclusion or removal decisions establish the subjects and relations; titles, co-lists, carriers, Reference entries, and configuration descriptions report them.
Existing material is hard to find, teach, or publish.	Use `E.11` for discovery, the relevant didactic pattern for teaching, `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. Use `G.5` only when the missing value is a selected-set result declaration.	Treat findability, teaching, and publication as their direct repair questions; architecture repair requires an architecture claim.
A cross-reference claims use, specialization, dependency, publication, source reuse, preservation, quality, deprecation, or supersession.	State the direct relation function and edition effect; open `E.4.PFR` only for its named maintenance consumer.	The link label remains a locator; the direct predicate states the relation meaning.
A framework split, dependency boundary, presentation-carrier or access-route choice, or adoption consequence must be decided.	Record one selected answer in an `E.9` DRR, using `E.4.PFAD` for its framework-specific content. Use `C.32.PAD` only when the decision is an exact project architecture decision and `C.32.ADR` only to project such a decision into an ADR-like publication.	The DRR carries the selected answer; diagrams, folders, manifests, PFAD relations, and project-specific projections may expose only their direct claims.
A source, search result, transformed view, or generated carrier supplies candidate material.	`G.2`, `C.33`, `C.34`, or `C.35` before architecture use.	Use the admitted source or preservation claim as authority for the declared contribution.
Whole-FPF adequacy, DPF package adequacy, individual pattern quality, repeated improvement, admission gating, or currentness is the live problem.	`E.2.DA`, `E.4.DPF.DA`, `E.21`, `E.23`, `E.19`, and `G.11` according to the claim.	Use the exact evaluation or refresh route for the live question; package and whole-FPF conclusions remain distinct from aggregated pattern scores.

This pattern should leave the reader able to state the architecture directly. Name the family member and selected pattern-language architecture, then state its dependency editions, publication or access carriers, preserved structures, and each neighboring claim under its exact predicate with the subject pattern as locator.