#Part E - The FPF Constitution and Authoring Guides

Preface node heading:part-e-the-fpf-constitution-and-authoring-guides:69483

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Vision & Mission: “Operating System for Thought”

#Problem frame

Modern engineering, science, and strategy all suffer from conceptual overload: dozens of domain tools, drifting vocabularies, and disconnected “best practices” splinter ideas as they travel from napkin sketch to certified deliverable. Stakeholders—Engineers, Researchers, Learners—lack a single, evolvable scaffold that can carry an insight across that span.

#Problem

Absent such a scaffold, every discipline re‑invents epistemology and systems thinking, spawning silos, steep learning curves, and brittle life‑cycle models. Previous attempts either froze agility in rigid hierarchies or dissolved rigour in tool‑centric jargon.

#Forces

Mission Statement

Enable any motivated system/actor/agent/transformer — human or AI — to transform a raw idea into a reproducible, auditable change in the physical world through incremental, falsifiable cycles.

Vision Statement

Reliable reasoning should be as accessible as version control: clone the conceptual kernel, extend it with domain patterns, and commit decisions that remain traceable across time, scale, and discipline.

#Solution — FPF as an Operating System for Thought

FPF delivers a generative scaffold realised as:

1. a Kernel of non‑derivable, cross‑domain first principles;

2. pluggable patterns—Systemic Calculus, Knowledge Dynamics, etc.—that instantiate those principles;

3. a pattern language (Architectural ► why/ how; Definitional ► what) with embedded Conformance Checklist (CC);

4. Design Rationale Records (DRRs) that govern safe, auditable evolution;

5. three core invariants that every artefact must honour

   • Evolvability — change is expected and governed;
   • Cross‑Scale Coherence — the same algebra binds parts to wholes at any level;
   • Didactic Transparency — each element exposes its own reasoning path.

#Conformance Checklist

#Consequences

Positive — Unified language accelerates cross‑disciplinary discovery; regulators can audit claim lineages; learners acquire concepts through the spec itself. Trade‑offs — Authors face an initial learning curve and must trace every rule to an invariant; disciplined traceability is required to prevent variant sprawl.

#Relations & Precedence

Pattern E.1 governs E.2 Eleven Pillars and the Guard‑Rail set A.5–A.8; any later pattern that conflicts with E.1 MUST be revised via a DRR before entering the Canon.

“Purpose without a scaffold is wishful thinking; a scaffold without purpose is cargo‑cult—FPF welds the two into disciplined imagination.”

#E.1:End

#The Eleven Pillars

#Problem frame

Pattern E.1 set the FPF mission as an operating system for thought. To turn that mission into a durable architecture, FPF needs a small, explicit constitution - principles that remain stable while everything built on top of them can evolve. Without such invariants, domain silos, vocabulary drift, and tool-centric shortcuts quickly erode coherence and reproducibility across disciplines.

The pillars are also the first-principles basis of FPF. They are the minimal commitments from which pattern-level work derives: decisive structure, teachability, maturing formality, open kernel, layering, register discipline, practical payoff, cross-scale consistency, explicit state, open-ended evolution, and SoTA renewal. Later patterns can support this basis by making a concrete argument about pillar support more inspectable; they do not replace pillar authority.

#Problem

Frameworks without binding first principles wobble between two extremes: rigid dogmas that kill adaptation and amorphous guidelines that invite cognitive chaos. In either case, reasoning fragments, auditability collapses, and physical impact suffers.

#Forces

#Solution

FPF rests on eleven non‑negotiable pillars. Each pillar is a binding constraint that every artefact, pattern, and design‑rationale record (DRR) must honour. Together they form the load‑bearing structure that guarantees evolvability, cross‑scale coherence, and didactic clarity.

When a pillar-impact argument relies on mathematical structure, scale behavior, optimization, uncertainty, invariance, obstruction, or other first-principles modeling support, the applicable mathematical-lens use support path is C.29. The pillar claim remains governed by E.2; C.29 only states the mathematical lens, preserved and lost structure, admissible use, neighboring-pattern exits, and stop condition that make the pillar support inspectable.

Any DRR that contradicts a pillar must first amend this constitutional pattern.

#Conformance Checklist

#Policy — Bitter‑Lesson Preference (BLP)

Intent. Favor general, computation‑leveraged, and freedom‑of‑action methods over hand‑tuned, brittle heuristics when safety and legality are held constant. This codifies the empirical trend that methods which scale with data, compute, and search breadth outpace bespoke rule‑engineering. Applicability: beyond ML, this policy covers search/optimization, control, simulation‑based inference, and other computational sciences where capability improves with scale and exploration. When NQD/E/E‑LOG promotes novelty/coverage (illumination) telemetry into dominance (via an explicit CAL policy; policy‑id recorded in SCR), these telemetry metrics are included in BLP comparisons for the audited window.

BLP‑1 — Scale‑Audit Requirement. Any DRR that selects a more specialized/hand‑engineered method over a general/scalable alternative MUST include a Scale‑Audit:

• (a) Parity harness: same ComparatorSet, freshness window, and evaluation seeds/replicates; set-returning evaluation (see G.5/G.9). Dominance criterion: Pareto‑only by default across the declared objective vector; any alternative requires a documented waiver by Gov‑CAL under E.3 precedence.
• (b) Budgets: sweep compute (steps/tokens/params/time/energy, as applicable), data (size/quality), and freedom‑of‑action (from script‑like instructions → minimal prohibitions) under a fixed risk/safety envelope. If any parameter cannot be swept, pin it and record the invariant.
• (c) Slopes & uncertainty: report ∂quality/∂compute, ∂quality/∂data, and (where applicable) ∂coverage/∂freedom‑of‑action and ∂novelty/∂budget; include error bars/CI from multi‑seed trials; publish edition pins and policy‑IDs in SCR/telemetry (G.11).
• (d) Resources: publish resource accounts for time/energy/FLOPs through A.15.1, A.15.2, B.1.6, C.16, and A.10 as applicable, and publish assurance deltas under B.3.
• (e) Objective declaration: list the objective vector (quality, risk, cost, and any illumination telemetry explicitly promoted into dominance via CAL with policy‑id recorded in SCR) used for Pareto comparison.

BLP‑2 — Preference Rule. Given admissibility and comparable assurance (within δ) and budget (within α), prefer the method whose slope vector is Pareto‑dominant over the audited range (per BLP‑1c/1e). If no dominance holds within error bounds, prefer the more general method (fewer domain‑specific heuristics, greater transfer via Bridges Φ/Ψ); otherwise resolve via E/E‑LOG tie‑breakers declared in policy.

BLP‑3 — Minimal‑Prescription Default. Author rules‑as‑prohibitions (negative constraints) over step‑by‑step scripts. Encode limits in Φ policy tables (and Φ_plane where applicable) instead of procedural checklists; allow the agent/system to sequence functions autonomously under those constraints (SoS‑LOG). Pre/post‑conditions and test harnesses remain permitted; scripts are permissible only when mandated by safety/regulation, or with compelling evidence recorded in the DRR and reviewed under E.3 precedence / E.5 Guard‑Rails.

BLP‑4 — Heuristic‑Debt Register. Any hand‑tuned rule admitted for pragmatic reasons MUST be registered as Heuristic Debt with: scope, responsible role, expiry/review window, measurable replacement target under BLP‑2, and a de-hardening/sunset plan. Track in CalibrationLedger/BCT (Baseline Change Tracker) and cite in SCR.

BLP‑5 — Continuous‑Learning Posture. Where product policy allows, enable feedback‑driven adaptation (e.g., preference learning, critique loops) within Guard‑Rails (E.5) and privacy/regulatory controls, with appropriate opt‑outs where required. Disabling adaptation requires DRR justification and a review date.

BLP‑6 — Precedence & Safeguards. BLP is a Gov/Arch policy instantiated by Pillars P‑10 (Open‑Ended Evolution), P‑11 (SoTA Alignment), P‑7 (Pragmatic Utility), and P‑1 (Cognitive Elegance). It does not override safety/ethics (E.5) nor E.3 precedence rulings; where BLP conflicts with Guard‑Rails, Guard‑Rails prevail. When NQD/E/E‑LOG elevates illumination to dominance for exploration mandates, BLP adopts that lens rather than overriding it.

Informative SoTA contexts (post‑2015): set-returning selection across LLM prompt‑programming vs fine‑tuned task models; preference‑learning families (RLHF ↔ DPO); QD archives (MAP‑Elites/CMA‑ME/DQD/QDax); open‑ended environment–method co‑evolution (POET‑class); offline RL vs Decision Transformer parity; and beyond ML, optimization/control (model‑based planning vs hand‑tuned controllers) and simulation‑based inference in the sciences. These are illustrative only; use the parity harness instead of single‑winner leaderboards.

#Conformance Checklist — BLP

#Relations

• Instantiates pillars: P‑10, P‑11, P‑7, P‑1.
• Depends on: G.5/G.9 (admission/comparator/selector and parity harness), G.11 (refresh telemetry), A.15.1, A.15.2, B.1.6, C.16, and A.10 for dated work, resource aggregation, measurement, cost, and provenance, C.18 (NQD-CAL), C.19 (E/E-LOG), and F.7/F.9 (Bridges, CL/Φ/Ψ). Planned C.5 (Resrc-CAL) may later consolidate resource-use and work-cost guidance but supplies no current governing semantics.
• Constrained by: E.5 Guard‑Rails (DevOps Lexical Firewall; Notational Independence; Cross‑Disciplinary Bias Audit) and E.3 precedence.

#Definitions

α (budget tolerance) may be relative or absolute; declare units (e.g., % cost, wall‑time, energy). δ (assurance tolerance) is the permissible delta in assurance under B.3; declare measure and floor(s).

#Consequences

Positive

• Provides an explicit “north star” for every contributor.
• Delivers a falsifiable checklist for evaluating proposals.
• Builds trust in high‑assurance domains through transparency.

Trade‑offs

• Constitutional review adds friction to rapid, informal changes.
• Amending the pillar set itself demands high‑bar governance.

#Rationale

The pillars are distilled from systems engineering, philosophy of science, software architecture, and ontology design. They interlock: Cognitive Elegance (P‑1) enables Didactic Primacy (P‑2); Open‑Ended Kernel (P‑4) and FPF Layering (P‑5) make Open‑Ended Evolution (P‑10) and SoTA alignment (P‑11) feasible; Cross‑Scale Consistency (P‑8) provides the algebraic backbone for Scalable Formality (P‑3). This minimal yet sufficient set balances stability with change, rigor with accessibility, and abstraction with measurable impact.

C.29 is a downstream support pattern for this constitution when mathematical first-principles structure is part of an argument about pillar support. It makes the structure, loss, and stop condition explicit while E.2 remains authority over what counts as a pillar.

#Relations

• Depends on: pat:constitutional/vision – pillars operationalise the mission.
• Refined by: All subsequent patterns in the Core Specification.
• Mathematical support path: C.29 supports pillar-impact arguments only for adequacy of mathematical lenses used to express first-principles structure. It does not amend pillar content, priority, or conformance.
• Governs: Every DRR, tool, and pedagogical artefact linked to FPF.

These pillars are not a cage but the load‑bearing columns of a workshop where ideas can be safely built, dismantled, and evolved.

#E.2:End

#FPF Pillar-Adequacy Evaluation CharacteristicSpace

Status: Core.

#Problem frame

Use E.2.DA when the object under improvement is an FPF-level object and the question is whether it realizes the E.2 Pillars adequately for a declared use. The object can be a monolith edition, selected pattern host set, pattern family, projection set, README/Preface/ToC publication change, access-carrier exposure such as a skill or MCP-backed route, release candidate, or whole-FPF edition.

Use it after a broad cleanup, new pattern family, projection repair, source-use repair, FPF-form change under E.4.FPF, or corpus-level improvement when local pattern quality is not enough. A set of good local patterns can still harm FPF entry, naming, layering, source use, projection integrity, or open-ended evolution.

Not this pattern when the evaluated object is one authored pattern version, one DRR, one local wording repair, or one pattern-use entry problem. Use E.21, E.9.DA, F.19, or E.11 respectively. Open E.10 or a precision-restoration neighbor for an unresolved FPF-specific wording question.

First useful move: name the FPF object under improvement by value, declared use, reader family, and qualification window; then evaluate all eleven Pillar coordinates. If a Pillar seems unaffected, give it a value and a short rationale saying what is preserved.

What goes wrong if missed: FPF can become locally polished but globally worse. Readers may find fewer useful entry points, precision repairs may erase the working move, source rows can turn decorative, or several patterns can grow local variants of the same doctrine.

Primary EntityOfConcern in plain terms: the scoped FPF object under improvement as an E.2 Pillar-realizing language object.

#Problem

E.2 gives the Pillars and their constitutional meaning. It does not by itself evaluate whether a concrete FPF object realizes those Pillars well enough for a concrete use. Without E.2.DA, corpus-level reviews tend to collapse into local pattern scores, process state, review praise, or broad claims that "FPF improved."

The specific failures are:

1. Local pattern quality is averaged into FPF adequacy.
2. Entry projections and companion files become separately maintained sources of definitions, constraints, or tests supplied by pattern bodies.
3. Precision repair improves terminology but damages first-use comprehension or changes the FPF kind carried by the repaired text.
4. Source and SoTA rows are counted rather than checked for changes in FPF moves.
5. Front-like words such as all 5s, exceptional, Pareto, SoTA, NQD, or shortlist become loose synonyms.
6. Corpus-level stop claims hide what became worse.
7. Pillar values become repair targets, so the corpus gains projection proof, entry apparatus, source rows, or review evidence while the FPF object becomes less usable, less layered, or less decisive.

#Forces

#Solution

E.2.DA is the Pillar-adequacy specialization of A.19.ECS. An evaluator applies its questions to one FPF object under improvement against all eleven E.2 Pillars for a declared use.

An E.2.DA result gives every Pillar coordinate a value, short rationale, evidence locus, and shared evidence basis for the FPF object being evaluated. Local pattern quality, DRR adequacy, and wording repair use their own object-under-improvement questions. A bounded diagnostic may borrow selected Pillar questions, but makes neither an E.2.DA-result nor an FPF-adequacy status claim.

#Local names and kind settlement

These names are local to the evaluation unless F.18 promotes a durable name. They name FPF content objects and evaluation fields, not release state, review state, or project evidence.

#Evaluation record

FPFPillarAdequacyEvaluation:
  FPFObjectUnderImprovementRef: <object and version named by value>
  FPFAdequacyUseScope: <entry | authoring | review | project use | source absorption | corpus release | other use named by value>
  FPFAdequacyReaderScope: <primary reader and working situation>
  FPFAdequacyQualificationWindow: <edition, source, neighbour, release, or comparison window>
  FPFPillarAdequacyEvidenceBasis: <checked pattern, host, monolith, projection, README, ToC, E.11, or I.2 entry locus, source, relation, companion, evaluation-result, and missing loci that affect values>
  FPFPillarAdequacyCoordinateTable: <all eleven coordinates, values, short rationales, evidence loci>
  FPFKindRestorationEvidence: <for broad wording or precision repair: changed span; pre- and post-repair object kind, relation or claim kind; current ontic slot, relation position, and use relation when part of the changed FPF-governed claim; admissible use and scope; concrete contribution of any cited pattern content; preserved, split, intentionally changed, or blocker disposition>
  FPFPillarAdequacyStatus: <status>
  StopOrRepairCondition: <local stop, first repair, Pillar decision, or architecture decision, and the smallest reopen locus or condition>

[E.22](/generated/patterns/E.22) may frame the evaluation purpose when the caller needs floor evaluation, exceptional improvement, trade-off inspection, open-question discovery, absorption, or proposal portfolios. [E.23](/generated/patterns/E.23) governs repeated improvement after the evaluation returns findings or candidate proposals.

#Ordinal coordinate scale

The values are ordinal content evaluations. They are not a scalar score, maturity ladder, release gate, or proof that development ends.

#Required Pillar coordinates

#Evidence and coordinate separation

One evidence locus may support several coordinates, but the rationale must say what property it supports in each coordinate. The following distinctions carry most repairs:

If a distinction cannot be recovered from the FPF object, lower the affected coordinate and state the first repair. Do not add a new local doctrine table to explain around the missing content.

E.21 and E.9.DA results are evidence loci for E.2.DA, not inputs to be averaged. A pattern-quality value can support a Pillar only by pointing to the FPF-level effect it creates or damages.

#Result-row discipline and calibration

An E.2.DA result uses this table shape:

For values 1..4, explain why the lower adjacent value would understate the evidence and the higher adjacent value would overstate it. For 0, explain why 1 would overstate the evidence and what would raise the value or reopen it. For 5, explain why 4 would understate the evidence and what would lower the value or reopen it.

A Pillar essay, local-quality average, two-column table, or result whose value depends on unchecked corpus, projection, or source evidence is not an E.2.DA result. It is only draft evaluation material. Missing or unchecked evidence lowers the Pillar coordinate that needs it; it does not make the coordinate optional.

Common calibration points:

#Status and stop condition

The stop condition states the declared floor, values, smallest reopen locus, and first repair when the declared use is not yet admissible. Add a non-use boundary only when an independently grounded reading by a plausible intended reader changes a named use.

#Compact result form

E.2.DA result:
  FPF object under improvement: <FPFObjectUnderImprovementRef>
  Declared use and reader: <scope>
  Qualification window: <window>
  Evidence basis checked: <FPFPillarAdequacyEvidenceBasis>
  Status: <FPFPillarAdequacyStatus>
  Coordinate table: <Pillar coordinate | Value | ShortRationale | EvidenceLocus for all eleven Pillars>
  First repair or stop: <repair | hold | local stop>
  Reopen if: <smallest changed locus or condition>

For a small release decision, the coordinate table may be compact. It is still complete. Status is not assigned from prose, a checklist count, a local-pattern average, a two-column table, or a result missing evidence loci needed by its values.

When [E.22](/generated/patterns/E.22), [E.23](/generated/patterns/E.23), absorption, or exceptional-improvement framing asks for improvement, below-floor Pillar coordinates return findings or repair. Above-floor coordinates receive proposal rows only for substantive non-dominated FPF-level content opportunities inside the declared use: for example, better entry recognition, placement of defining, constraining, or testing content, source-currentness carry-through, projection thinning, corpus-ecology repair, kind-preserving precision restoration, open-ended evolution support, or deletion or relocation of apparatus that weakens the FPF object. Apparatus-only additions do not qualify. Do not treat every value below 5 as a defect. A 4 may be the correct stop value only with loci showing why further Pillar-content movement is dominated, unavailable, or outside scope.

#Worked slices

Broad precision cleanup. A wording pass makes many patterns more admissible but several Problem frames now explain less about why the distinction matters, or a cleaned phrase changes the governed kind while the trigger word disappears. P2, P6, and P7 receive lower values until the affected patterns restore recognition reason, useful action, and pre-repair and post-repair kind evidence in admissible wording.

Ontic architecture repair. A campaign adds E.24.CD, E.24.PUB, or a new ontic host. Pillar values rise only if the change reduces duplicate ontology, type explosion, or shadow authority and improves FPF entry, authoring, review, or project use. Extra ontic terminology, score proof, or publication-boundary prose without better action lowers P1, P2, P5, P6, and P7.

Repeated content, route, reference, neighbour-reference, and negative-fanout cleanup that weakens content. A corpus pass removes repeated "not proof", "not gate", and "not work" prose, route metaphors, repeated guards, repeated mini-rules, repeated conditional neighbour-reference mappings, reference boilerplate, or architecture-placement prose, but leaves several patterns with less positive ontology, method, norm, or worked action than before. P2, P5, P6, P7, and P10 receive lower values until the affected patterns restore their own subject content and state each cited pattern's concrete contribution.

Projection repair. README scenarios, ToC rows, E.11 entry-distribution loci, and I.2 expanded entry-disambiguation cases improve search but can become separately maintained sources of pattern rules. P5 and P9 fall when projections become shadow sources. The repair places each authored definition, constraint, or test in the pattern body that supplies it and preserves the public aid's E.11 function. A locator remains a locator; an ordinary entry or Practical-Use Card retains its source-linked first-use guidance, including the first useful result or honest blocker and stop or wrong-turn return.

Source absorption. A new source family adds current methods, but pattern bodies only cite it. P11 stays low until source rows change selected actions, examples, checks, or stop conditions. P7 changes only when the source changes action.

#Bias annotation

This pattern biases FPF toward whole-language adequacy. The bias is useful because local repairs often hide corpus-level loss.

The bias is bounded by the object-under-improvement declaration. E.2.DA does not replace E.21, E.9.DA, E.10, E.11, or E.23; it evaluates their FPF-level Pillar effect when the scoped FPF object includes their results.

#Conformance checklist

#Common anti-patterns and repairs

#Relations

#Rationale

FPF needs a corpus-level quality instrument because the language can degrade while individual pattern edits look successful. The complete eleven-coordinate evaluation prevents the common escape hatch: "this is only a local repair" repeated across many files until Pillar realization changes.

The instrument is still affordable because it asks for short rationales and evidence named by value loci. It does not require a new review process, full audit bundle, or exhaustive evidence or source-material dossier.

#SoTA-Echoing

#Consequences

#E.2.DA:End

#Principle Taxonomy & Precedence Model

#Problem frame

Pattern E.2 supplies eleven immutable pillars, yet experience shows that a flat list of principles invites ambiguity: reviewers cannot decide which pillar overrules another and “dead‑letter” rules accumulate.

#Problem

When two pillars or derived principles pull in opposite directions, architectural decisions stall—or worse, drift toward the loudest voice. Without an explicit taxonomy and precedence cascade, FPF risks devolving into subjective debate, breaking its claim to be a rigorously auditable “operating system for thought.”

#Forces

#Solution

#Principle Taxonomy

Every principle is an instance of U.Principle assigned exactly one class ∈ { Gov, Arch, Epist, Prag, Did }.

Epistemological sub‑concerns (reasoning, falsifiability) reside inside Onto, avoiding category sprawl yet keeping semantics and trust in one bucket.

#E.3:4.2 - Precedence Stack

Within the precedence stack the default order is: Gov ≫ Arch ≫ Epist ≫ Prag ≫ Did

Graph Rule — The precedence graph MUST be acyclic; any new edge that would form a cycle is rejected.

Governance principle vs Architectural principle clash: e.g. Core release schedule (Gov) outranks performance‑tuning (Prag)

#Conformance Checklist

#Illustrative Conflict Resolution

1. The Conflict

   • P‑1 Cognitive Elegance (Arch) demands an unambiguous term for “part–whole” entities, pushing us toward Holon.
   • P‑2 Didactic Primacy (Did) values immediate practitioner familiarity, pushing us to retain System.

2. Risk of Stalemate Without a precedence cascade, the discussion would collapse into subjective argument: “purity beats clarity!” vs “clarity beats purity!”.

3. Applying the Precedence Model

   • Default order: Gov ≫ Arch ≫ Epist ≫ Prag ≫ Did.
   • Arch outranks Did; therefore P‑1 takes formal precedence over P‑2.

4. Principled Decision We adopted Holon to satisfy the higher‑priority principle and mitigated the didactic cost by:

   • declaring System ≡ U.System ⊑ U.Holon,
   • providing aliases and an “On‑Ramp” tutorial.

The precedence rule did not merely name a winner; it compelled a solution that honoured both principles in proportion to their rank.

Precedence (high → low). Law & Regulation → E.5 Guard‑Rails → B.3 Trust & Assurance → E.3 governance decisions → E/E‑LOG policies (editioned) → BLP (E.2) → Product Policies → Implementation Tactics.

Notes.

• BLP is a constitutional policy (see E.2 / “BLP”), but does not supersede E.5 Guard‑Rails nor B.3 assurance floors; it does govern ties among lawful, comparable‑assurance options.
• Wherever NQD/E/E‑LOG promotes illumination telemetry to dominance (via an explicit CAL policy; policy‑id recorded in SCR), BLP adopts that lens rather than overriding it (see E.2 BLP‑6).
• Any exception to policy MUST include a DRR with rationale and expiry.
• BLP Override (Waiver). When a narrower hand‑engineered method is selected over a general/scalable alternative within declared tolerances (α = budget, δ = assurance), the DRR MUST include:
  • a BLP Scale‑Audit (see E.2 BLP‑1) covering compute/data/freedom‑of‑action sweeps and slope/uncertainty reporting,
  • the tolerances α/δ and objective vector used (E.2 BLP‑1e),
  • a Heuristic‑Debt entry (responsible role, scope, expiry/review, de-hardening plan) per E.2 BLP‑4,
  • an AutonomyProfileId (see E.3‑ABL) and the GateDecision authority (see Gate‑decision authority map below). Set-returning parity. All precedence decisions that compare methods MUST use the G.5/G.9 parity harness and Pareto dominance; scalarisation across mixed scales/units is prohibited (B.3).

BLP — Bitter‑Lesson Hooks into Precedence

1. Tie‑breaking. If two lawful options are within δ assurance and within α budget, prefer the option whose slope vector Pareto‑dominates over the audited window; if no dominance, prefer the more general method. (E.2 BLP‑2.)
2. Script‑vs‑Search conflicts. For conflicts between procedural scripts and general search/learning, scripts prevail only when mandated by E.5 or regulation, or when a DRR records a BLP‑waiver with expiry and hazard rationale (E.2 BLP‑3/6).
3. Publication. Precedence rulings that reference BLP MUST publish editioned policy‑IDs, edition pins, and resource accounts whose planned values, dated Work, aggregation, units, and provenance follow A.15.2, A.15.1, B.1.6, C.16, and A.10, respectively, to the SCR (E.2 BLP‑1d; G.11).

ABL — Autonomy‑Budget & Oversight Profiles (GateProfile) This section defines an extensible family of autonomy oversight profiles for agentic tool use: each profile specifies (i) a budget envelope, (ii) a Freedom‑of‑Action (FoA) descriptor, and (iii) the required gate‑decision publication to authorize execution under that envelope. The familiar labels L0…L4 are treated here as profile identifiers (not a fixed managerial ladder): projects MAY introduce additional profiles or sub‑profiles by minting new profile ids, provided they publish the same fields (budgets, FoA, decision roles, telemetry requirements) and keep profile changes explicit and auditable.

Normative requirements by profile.

• Budgets. Each profile MUST declare ceilings for time / compute / cost / risk and a FoA descriptor; units must be explicit under C.16, planned ceilings remain A.15.2 WorkPlan content, and run‑time consumption is tied to dated Work, aggregation, and provenance under A.15.1, B.1.6, and A.10. Budgets are hard gates at run‑time (C.Agent‑Tools‑CAL ATC‑3).
• Profile binding & change visibility. Every CallPlan MUST declare the active profile id. Any profile change is a GateCrossing (E.18) and MUST be published (DecisionLog entry + pinned policy‑ids), so an auditor can reconstruct which profile governed which Window.
• Assurance floors. B.3 WLNK minima on F and R apply at all profiles. Any profile‑specific tightening (e.g., higher required R_eff or stricter CL/Φ policies for broader FoA) MUST be declared on the profile and pinned by policy‑id. Pre‑deployment assurance deltas MUST be recorded for L2+.
• Exploration discipline. explore_share MUST be explicit in the CallPlan (C.Agent‑Tools‑CAL ATC‑4). Deviations from defaults require DRR justification.
• Provenance. L1+ MUST emit a CallGraph with Service/Method editions, EmitterPolicyRef, budget deltas, and observation hooks (C.Agent‑Tools‑CAL ATC‑5/6).
• BLP conformance. For L2+, selection MUST apply BLP (E.2 BLP‑2) with α/δ tolerances declared in the plan policy. Any admitted heuristic requires a Heuristic‑Debt entry (E.2 BLP‑4).
• Learning/Adaptation. L3–L4 MAY enable feedback‑driven adaptation within E.5 Guard‑Rails and privacy controls; L0–L2 default off unless a DRR documents mitigation (E.2 BLP‑5).
• Human‑in‑the‑Loop (HITL). HITL obligations are expressed as gate decisions and pause/resume hooks, not an implicit “approval ladder”:
  • L0–L1: execution MAY start only after an explicit GateDecision authorizing the CallPlan is present in the declared window.
  • L2: sentinels MUST be able to pause execution; resumption requires a new GateDecision recorded in the DecisionLog.
  • L3: the profile MUST declare periodic review windows; continued execution across a review boundary requires an explicit GateDecision.
  • L4: continuous telemetry review; the default execution context is sandboxed; leaving the sandbox requires an explicit GateCrossing with a published CrossingBundle (E.18 + F.9/F.17/E.17, with A.21 when a gate decision is live).

Gate‑decision authority map (default signers; who may author GateDecisions).

• L0: EoR or appointed maintainer.
• L1: EoR and peer reviewer (two‑person rule).
• L2: Team Lead and Safety representative.
• L3: Product Owner and Safety and Legal/Privacy.
• L4: Gov‑CAL Board (multi‑disciplinary) with documented scope, time‑boxed trial budget, and rollback criteria.

Profile promotion / demotion triggers.

• Promote a profile when repeated BLP‑consistent results show stable assurance within δ and budget adherence within α for ≥ N_policy runs (declare N_policy in the active profile). Promotion is not implicit: a GateDecision MUST authorize the profile change and cite the slope evidence (E.2 BLP‑1c).
• Demote a profile when: (i) a sentinel breaches risk or budget, (ii) assurance drops below floors, (iii) policy changes, or (iv) a significant heuristic‑debt item expires without replacement. Demotion MUST be published as a GateCrossing with updated budgets/policies pinned.

#Conformance Checklist — E.3 ↔ BLP Interop

#Consequences

Positive — Turns subjective debate into objective, traceable decisions; high‑impact conflicts surface early.

#Rationale

The chosen taxonomy mirrors FPF’s layered dependency: Governance rules how change occurs; Architecture shapes what can exist; Epistemology secures meaning and trust; Pragmatics and Didactics ensure usefulness and learnability. Explicit override edges supply the flexibility experts need, while the default hierarchy keeps day‑to‑day design deterministic—a “living constitution” that remains both human‑intelligible and machine‑enforceable.

#Relations

• Depends on: pat:constitutional/vision, pat:constitutional/pillars
• Governs: All subsequent patterns and DRRs; Guard‑Rail patterns reference CC‑PT.\

“A taxonomy sorts principles; precedence gives them order—together they convert debate into design.”

#E.3:End

#FPF Ecosystem Family Architecture

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

#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 renders a selected architecture in pattern-language form for a declared reader and use. That architecture covers recurring problem situations, forces, known failure modes, reusable SoTA solution moves, consequences, cases, relation records, evaluation methods, and refresh conditions. 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 result or service, 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. Include blockedOverreadRefs only when [F.19](/generated/patterns/F.19)'s grounded-contribution test admits them; otherwise omit the field. The record carries a contextual ecosystem answer; the subject claims and patterns it cites remain its content sources and semantic loci.

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. Use these compatible views and scopes for their respective questions.

#Place support units and adjacent products deliberately

In this pattern, product is Plain management wording for a deliberately identified result or service boundary. It helps a team state intended use, identity or current state, access, later change and retirement rules, and any maintenance that actually obtains. 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, publication, availability, 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. Constitution or publication establishes only the claims made by those acts; maintenance and future Work need their own evidence. If the direct kind or relation is not settled, keep the management boundary as a proposal and return that question instead of inventing a common object kind.

A framework edition is an 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, and change rule. Being outside the pattern set or in another file does not by itself create another product or a maintenance claim.

Make a separate adjacent product only when people need to change, cite, or use 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 later-review or retirement rule, or cross-framework reuse or reliance. A separately established maintenance relation may also matter, but product identity does not require it. Examples include a registry, MethodDescription collection, evidence package, guide, tool reference, access service, or inquiry programme; other direct subjects may also 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. File location does not decide the boundary.

When the direct subject is independently used or changed, 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, later-change and retirement rules, and any separately established maintenance relation; the outer navigation names the 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 its own edition and change 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 and any provider System, maintenance relation, accepted commitment, or service state that independently obtains. 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 development or process evidence by default. They become reader products only when a selected public use gives a direct subject its own product identity and publication or availability route.

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, and change rule; test a proposed adjacent subject for independent use and change; select the smallest useful boundary; then record exact pointers, snapshot return, and neutral-carrier navigation. Establish maintenance only when a maintained claim is made. 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 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. 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:

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. 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.
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 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.
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. Its rows are common routes, not a closed taxonomy:

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.

#Archetypal Grounding

Tell: A team creating a hydroponic-cucumber domain principle framework creates a domain framework edition grounded in FPF Core and horticulture SoTA. It declares its dependency on an FPF Core edition and records its source packs. The team 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 are local framework material. A Core-amendment decision under E.9 remains the route for changing FPF Core.

Show: A generated relation graph over pattern names can help inspect missing relation assertions. After C.35 admits the carrier, state each supported relation directly. Open a reusable E.4.PFR row only when a named maintenance consumer requires it.

Show: In the cucumber DPF, the Readme, table of contents, pattern collection, and coverage account share one framework edition, reader use, access route, and change rule, so they remain publication units of one product. A greenhouse-calibration source registry has its own edition rule and is reused by another crop DPF, so its current registry edition is a separate episteme. One web carrier may expose both while preserving their exact identities and direct relations.

#Bias-Annotation

Scope: limited. This pattern helps make architecture claims about FPF-grounded framework ecosystems and their publication, access, companion, service, and separately established maintenance boundaries. Product taxonomy, service design, programme ontology, and content management remain with their direct patterns.

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

An ecosystem-architecture record identifies the selected structures across FPF patterns, frameworks, source packs, exact presentation carriers, access routes, quality records, and decisions. Direct assertions state relation meaning and decision rationale. Source-return and currentness patterns qualify carriers and access routes. Architecture work therefore names the selected structures and applies the relevant direct pattern to each neighboring claim.

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

Use official catalogues, vocabulary standards, current release pages, tool documentation, lineage sources, and source-maintenance checks only for their stated source or default contribution. Product kind, service kind, publication identity, relation truth, and SoTA rank each require their direct evidence and pattern.

#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 named maintenance consumer needs a reusable relation, edition, dependency, compatibility, deprecation, or preservation record; otherwise state the direct relation assertion.

• 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 constituted 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

#First Principles Framework Form and Publication-or-Access Carrier Assembly

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

#Problem frame

Use this pattern when an FPF steward, framework author, reviewer, or AI agent must assemble, expose, or evaluate FPF itself as one framework edition and distinguish it from its publication units, forms, presentation carriers, access routes, and domain or local dependents.

Primary EntityOfConcern: the scoped FPF edition (FirstPrinciplesFrameworkEdition) being assembled, exposed, or evaluated. The first useful output is a record for rebuilding that edition. It names the first-principles scope, selected Core patterns, recurring cross-domain problems and reusable solution moves, selected publication units and forms, exact publication- or access-facing U.PresentationCarrier values, access routes, edition relations, and the applicable whole-FPF quality result from E.2.DA. Add an exact competing-reading reference only under the full F.19:4 test: independent local ground, plausibility for the intended reader, a change in truth, understanding, or use, and the smallest clear correction.

Use this when the work changes FPF publication units or forms—such as the public opening, Readme, Preface, ToC, first-entry view, cards, or split pattern collection—or assembles the exact physical or digital carrier that bears them, such as an all-in-one file, site snapshot, volume, or bundle. Use it also when a skill-pack carrier or an MCP, retrieval, search, or assistant access route exposes the edition. When a public presentation carrier is in scope, use E.11.PFP for its common reader-facing form and this pattern for FPF-specific source selection and assembly. Use E.4.DPF instead when the framework is a domain or local framework grounded in FPF. Use E.4 when the live question is only family placement and routing among framework members.

The practical payoff is direct. A reader can identify the FPF edition, the reader-facing units and forms that expose it, and the exact presentation carriers that bear them. The same account names its access routes and whole-FPF adequacy route. A DPF or local framework may depend on FPF Core while remaining its own framework edition.

#Problem

After DPF and local-framework publication forms become explicit, FPF itself can fall into the opposite omission: DPF packages get careful publication-unit, form, carrier, relation, naming, quality, and refresh rules, while FPF is treated as if its form were self-evident because it is "the main spec".

That creates several failures:

• an all-in-one file or site, one of its Readme, Preface, ToC, pattern-body, card, or first-entry units, a skill-pack bundle, or an MCP route is mistaken for the FPF edition itself;
• FPF is described as one more DPF, losing the first-principles and transdisciplinary burden that makes DPFs possible;
• whole-FPF quality is checked by local pattern scores, landing status, or DPF package scales instead of E.2.DA;
• adoption units, forms, or access surfaces grow user-facing explanations that quietly become shadow authority beside subject patterns;
• skill or MCP access makes FPF look like a callable service, tool permission layer, or runtime dependency rather than a framework edition reached through an access route or borne by an exact access-facing presentation carrier.

Use an FPF-specific form rule. FPF must keep first-principles distinctions usable across domains while allowing domain and local frameworks to grow from it; E.4.DPF governs those dependent frameworks.

#Forces

#Solution

Treat FPF as a FirstPrinciplesFrameworkEdition: one transdisciplinary edition with a selected Core pattern set and a stated first-principles scope. Record its recurring cross-domain problems, reusable solution moves, edition relations, publication units and forms, exact presentation carriers, and access routes under their direct subjects and relations, and coordinate them within that edition. Units and forms expose selected content; presentation carriers bear the selected forms; access routes help an audience or system reach them.

Use these local names:

The progressive-minimum F.18 NameCard NC-FPF-EDITION-REBUILDABILITY-RECORD names the family of claim-bearing records defined by the FPFEditionRebuildabilityRecord row and declaration in E.4.FPF:4; that section is also its subject-pattern locator. This is an ordinary record family. Keep a particular record, its Markdown carrier, the assembly Method, the performed assembly Work, and an actual E.10 Map under their direct kinds.

The NameCard uses FPFCoreReferenceScheme by value. In that scheme, FPFEditionRebuildabilityRecord designates only the record family whose instances concern one FPF edition and name the exact sources, publication units and forms, presentation carriers, access routes, relations, projections, quality and currentness results, and refresh routes needed to reconstruct its public form. No Bridge is claimed. Use the Tech designation in edition and rebuildability records, maintainer diagnostics, and direct consumers; use the Plain designation “record for rebuilding one FPF edition” in ordinary practitioner explanation.

The name comparison covers FPFEditionRebuildabilityRecord, FPFEditionAssemblyRecord, FPFEditionSourceAndCarrierIndex, and the predecessor FPFFormMap: rebuildability-record, assembly-record, index, and mapping-Method readings. AssemblyRecord is too narrow because the record also names relations, projections, quality, currentness, and refresh inputs; assembly itself is the subsequent operation. SourceAndCarrierIndex is too narrow because the record must also keep publication units, forms, and access routes distinct. FormMap is retired rather than kept as an alias because E.10 reserves Map for a mapping U.Method. Reopen this settlement if the named family becomes such a Method, ceases to concern one edition's reconstruction inputs and routes, FPFCoreReferenceScheme or the local-sense claim changes, a direct consumer needs another distinction, or a narrower admitted record kind covers every current field and use.

Current FPF practical-entry declaration. Apply E.11's content test to every proposed example. The current English FPF Readme declaration is:

This is the one FPF declaration consumed by Readme authoring, assembly, and validation; do not maintain another ordinary-entry or card list. It declares nine ordinary examples and thirteen cross-pattern cards, not the scope or limit of FPF help. The Readme must say that FPF and the applicable DPF or LPF can answer a much wider range of questions and must return a reader whose question fits no example to the Table of Contents, another finding aid, or the direct patterns.

The selection answers the declared current reader-use questions and passes the no-mantra comparison; it does not claim observation of reader behaviour and does not reproduce the historical fifteen seminar cards or the predecessor twenty-key list. Distinct predecessor questions remain recoverable without keeping one selectable entry for each topic: CAPABILITY-DEVELOPMENT is carried by PRACTICE-ARCHITECTURE and IMPROVEMENT; COSTLY-ACTION is carried by OPTION-COMPARISON; DESCRIPTION-USE is carried by WORKING-DOCUMENTS; and DPF-AUTHORING is carried by SOTA-PORTFOLIO.

TIME, CAUSAL-USE, MEASUREMENT, and MATHEMATICAL-MODELING are ordinary examples because each starts with one direct pattern and can stop at its first useful result without a cross-pattern mantra; no MODELING-FOR-ACTION card joins them. LIVE-WORK-STEERING and METHOD-RECOVERY are ordinary examples for the same reason: each begins at one direct pattern and may stop at its first useful result or honest blocker. PROFESSIONAL-RESULT is also ordinary: it starts with A.15.9, tests an already-available result before any new request, and can stop at bounded reuse, the smallest missing-result request, or an honest blocker without a cross-pattern mantra.

COMMUNICATION-FOR-USE is selected as a card because the same truthful five-field entry without a mantra still identifies the situation, first result, and direct patterns but reduces the cross-pattern dependency to a flat list. After interruption, that list no longer carries the sequence from receiving use through the communication that occurred, its wording or representation, use-relevant evidence, later effect, causal qualification, and repair or stop; the compact mantra restores that choice-changing sequence.

RESULT-TO-NEXT-MOVE is a card because it keeps the conditional path from an obtained result through only the interpretation, reliance, characterization, comparison, or live-choice question that is current, with a stop at every other boundary; a flat locator list would not preserve those conditions.

CONSEQUENCE-BEARERS is a card because its compact mantra preserves the repeatable boundary challenge and return sequence needed to keep candidate Systems, obtaining relations, modal paths, holon recovery, uncertainty, and the receiving use distinct; a flat locator list would lose those choice-changing conditions.

ACTUAL-TEMPORAL-STRUCTURE is a card because its compact mantra preserves the conditional sequence from actual changing subjects and direct obtaining relations through one selected structure and grounded account to separately admitted future specifications and representations, then to a bounded coordination trial, observation, decision, or stop; a flat locator list would lose those choice-changing distinctions and cheap exits.

PUBLICATION-FORM and DPF-SUITE-REFERENCE remain direct locators to E.11.PFP and E.11.DSG, not selected examples. Exact content stays in those direct patterns; the Readme carries only the recognition, cross-pattern dependency, and return needed for discoverability.

For every card row, keep the card and its practical-use guidance findable by the same key. The current English FPF counts whitespace-separated tokens and requires at most 80 for a card mantra and 220 for a complete compact card. These are maxima with no minimum length. They are calibrated publication envelopes for this English FPF, not psychometric thresholds or universal DPF, LPF, or translated-publication limits. Reopen the smallest affected declaration row and consumer when a cold-reader replay loses a choice-changing distinction, a useful card cannot fit without copying direct-pattern apparatus, or either ceiling can be lowered without losing use value. The optional @FPFReadme support records may carry FPF links but do not define shared conformance. Create the FPF edition rebuildability record with this shape when FPF itself is being assembled, republished, exposed, or evaluated:

FPFEditionRebuildabilityRecord:
  recordRef: <exact rebuildability-record identifier>
  firstPrinciplesFrameworkEditionRef: <FPF edition named by value>
  firstPrinciplesScopeRef: <transdisciplinary scope and non-domain boundary>
  selectedCorePatternSetRefs: <exact selected complete pattern-source refs or declared sections of an accepted source edition>
  selectedFirstPrinciplesProblemSituationRefs: <recurring cross-domain problem situations and forces rendered by the edition>
  selectedFirstPrinciplesSolutionMoveRefs: <reusable solution moves, consequences, and repair routes rendered by the edition>
  selectedPublicationUnitRefs: <selected FPF content-unit refs, for example: public opening | standalone Readme | Preface | ToC | pattern-body collection | card set>
  selectedPublicationFormRefs: <exact arrangements or rendering conventions selected to express those units for named uses>
  selectedPublicationCarrierRefs: <exact U.PresentationCarrier refs that bear selected public forms, for example: all-in-one Markdown file | PDF volume | website snapshot | split-file bundle>
  selectedAccessCarrierRefs: <exact U.PresentationCarrier refs that bear access-facing forms, for example: skill-pack bundle | retrieval-index file | response document>
  selectedAccessRouteRefs: <identified services or routes, for example: MCP service | retrieval route | search function | assistant integration>
  relationAndEditionRefs: <direct relation and edition assertions, including edition pins and dependency boundaries; E.4.PFR rows only for a named maintenance consumer>
  firstEntryAndProjectionRefs: <E.11.PFP, E.11, E.17, I.2, Readme, Preface, ToC, and other contribution or projection loci>
  publicationSelfRenderingRefs: <statements in selected publication units of reader, selected first-principles structures, deliberate coarsening, abstraction, omission or deferral, and return to subject patterns, for example: Readme | Preface | ToC>
  qualityAndImprovementRefs: <E.2.DA for FPF-level adequacy; E.21, E.23, and E.9.DA as evidence or local routes>
  currentnessAndRefreshRefs: <G.11 plus exact source-use and currentness records>
  blockedOverreadRefs: <optional exact refs to explanatory guards admitted by F.19:4's plausible-reader and grounded-contribution test>

These fields preserve the existing rebuildability content while making unit, form, presentation-carrier, and access-route references explicit. firstPrinciplesFrameworkEditionRef resolves to the edition record for the selected FPF edition; relationAndEditionRefs resolves that edition's status and dependency assertions. Keep DPF or LPF package records separate instead of copying them into this record. The rebuildability record supplies reconstruction inputs; downstream assembly and use claims come from their direct results and relations.

The ordinary method is:

1. Name the FPF edition or edition candidate being assembled by its stable designation and exact edition record.
2. State the first-principles scope: FPF supplies transdisciplinary distinctions that can be reused across domains. Domain doctrines remain with their DPFs; the declared scope sets the useful coverage boundary.
3. Identify the selected Core pattern set and any companion or projection loci that expose it.
4. When a public presentation carrier is being assembled or checked, use [E.11.PFP](/generated/patterns/E.11.PFP) for the common publication form. Keep a product-declared compact opening and separate exact title and Readme H1 values. Represent Readme and Preface in the product's established ToC grammar before one logical pattern index. Keep one explicitly non-exhaustive practical-entry set, five-field ordinary examples, six-field selected cards, and one integrated source-hazard plus rendered-structure check. Apply [E.11](/generated/patterns/E.11)'s use test before assigning card form, and use the current FPF declaration above for every selected key and form plus the English reading-burden measure and two limits. Add another public cue only when a named reader decision or action needs it. For the established all-in-one FPF carrier, add Readme through the same non-pattern table grammar already used for Preface, preserve the compact pre-ToC shape, and keep the exact line-position and native-ToC assertions in the builder regression. Keep FPF-specific source selection, body order, and assembly here; the carrier and form remain separate from the FPF edition.
5. Separate the objects before recording them. Readme, Preface, ToC, the public opening, cards, and the pattern collection are publication units; their selected arrangement is the publication form. Name the exact U.PresentationCarrier—for example, a versioned Markdown file, site snapshot, PDF volume, split-file bundle, skill-pack bundle, index file, or response document—only when it actually bears that form. Record an MCP service, retrieval route, search function, or assistant integration as an access route; name any returned carrier separately. The FirstPrinciplesFrameworkEdition coordinates these units, forms, carriers, and routes as distinct subjects and relations.
6. State relation, dependency, edition, deprecation, supersession, publication, and access claims directly. Open an [E.4.PFR](/generated/patterns/E.4.PFR) row only for a named maintenance consumer.
7. Keep downstream direction clear: DPFs and local practice frameworks may depend on FPF Core; FPF Core does not depend on them except by a deliberate Core amendment decision.
8. Fill the existing FPFEditionRebuildabilityRecord with exact selected source, publication-unit, publication-form, presentation-carrier, access-route, relation, practical-entry declaration, currentness, and refresh references. Make the Readme assembly and its checks consume the same declaration rather than another key or card list. Do not create a rival manifest or duplicate rebuildability account.
9. Assemble the all-in-one edition candidate from the exact predecessor, the selected edition record, the matching FPFEditionRebuildabilityRecord, and every selected complete pattern source. Give each replacement or insertion an explicit boundary. Derive the logical index and pattern bodies from the same selection, verify one index row per selected PatternID, report which source supplied each assembled unit, and verify that every unselected predecessor span is unchanged. A missing or duplicate record, unresolved ref, index/body mismatch, ambiguous boundary, source mismatch, or changed unselected span stops construction. The construction result reports the assembled candidate and source correspondence; acceptance and publication require their separate decisions and relations. Keep repository paths, commands, helper options, template names, and insertion syntax in maintainer documentation or the selected tool's help.
10. When the assembled publication claims accepted-source integration or continuity with its predecessor, use [E.4.PFIP](/generated/patterns/E.4.PFIP) for that comparison. For whole-FPF adequacy, use [E.2.DA](/generated/patterns/E.2.DA) over the scoped FPF object and declared use. Use [E.21](/generated/patterns/E.21) for individual pattern bodies, [E.9.DA](/generated/patterns/E.9.DA) for a DRR, and [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) only for DPF or local-framework packages.
11. For first-entry and reader-facing exposure, use [E.11](/generated/patterns/E.11) and [E.17](/generated/patterns/E.17); keep their projection text thin enough that subject pattern authority remains in the patterns.
12. Make the FPF Readme, Preface, and ToC publication units structure-account-aware: state the reader and use they serve, which first-principles structures they foreground, what they deliberately coarsen, abstract, omit, or defer, and where the reader returns for subject-pattern detail. Use [E.11.PFP](/generated/patterns/E.11.PFP) for the common publication-form structure. Preserve the product-declared compact opening, put the direct Readme/Preface route before the logical pattern index, and keep source paths, digests, machine identity blocks, candidate records, and build instructions outside reader front matter.
13. For source-front, currentness, and refresh claims, use the direct [G.2](/generated/patterns/G.2) and [G.11](/generated/patterns/G.11) assertions. Publication units, forms, presentation carriers, and access routes contribute only their stated publication or access facts.
14. For skill packs or MCP-backed access, expose edition identity, dependency boundary, and currentness or refusal conditions. Distinguish the exact skill-pack, index, or response carrier from the service or route that returns it. Generated candidate text goes to [C.35](/generated/patterns/C.35); keep tool capability and Work claims separate, using the applicable tool pattern for the former and [A.15](/generated/patterns/A.15) plus the pattern for the exact Work for the latter; use the applicable patterns for assurance, evidence, and decision-authority claims.

Use this quick routing test:

#Archetypal Grounding

Tell: A later FPF edition updates its public front, Readme, Preface, ToC, and several pattern bodies. The FPF edition rebuildability record names one scoped edition, lists its Core pattern set, publication units and forms, exact presentation carriers, and access routes, records which entry text is only a projection, and points to E.2.DA for whole-FPF adequacy. It records Readme and Preface as publication units and names a presentation carrier only under an exact PublicationFormBearingRelation.

Show: A domain principle framework for any one practice depends on FPF Core and may cite architecture, representation, precision, and improvement patterns from FPF. Its publication units, forms, exact presentation carriers, and access routes belong to that DPF edition. Its package adequacy uses E.4.DPF.DA; FPF Core retains its transdisciplinary scope and its own amendment route.

Show: An FPF skill pack exposes pattern lookup, first-entry guidance, and short-use prompts. A versioned skill-pack bundle can be an access-facing U.PresentationCarrier; the service, endpoint, or assistant integration that returns it is an access route. Their descriptions name the FPF edition they expose and its refresh condition. Authority claims return to the named subject pattern and edition.

Show: One FPF edition replaces two complete pattern sources and inserts a third while every other pattern body must carry forward from the predecessor. The rebuildability record names the predecessor, edition record, complete selected sources, publication units and forms, exact output carriers, and any access routes. Assembly gives each changed body an explicit replacement or insertion boundary, rebuilds the logical index from the same selection, checks source-to-body correspondence, and verifies that unselected predecessor spans are unchanged. Any mismatch stops construction. A successful construction reports the candidate and source correspondence; acceptance and publication require their separate decisions and relations.

Mini-map:

#Bias-Annotation

Scope: Limited to the publication units and forms, assembly, exact presentation carriers, access routes, and whole-framework evaluation route of an FPF edition. Repository layout, assembly tool, carrier split, and publication service remain implementation choices. A one-sentence repair that leaves these FPF-level values unchanged uses its direct wording and source route.

#Conformance checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

FPF adoption becomes easier to reproduce because authors can build Readme, Preface, ToC, and pattern-body publication units; arrange them in all-in-one or split forms; bear those forms on exact files, sites, volumes, or bundles; and provide skill, MCP, search, or retrieval access without changing what FPF is. The same declaration keeps FPF's few direct and cross-pattern examples, their forms, and the two reading-burden limits aligned across authoring, assembly, and validation. Explicit non-exhaustive wording lets the examples promote pattern-language use without turning the Readme into a catalogue or forcing a card onto every entry.

The cost is one extra distinction for stewards: whole-FPF form is not the same problem as DPF authoring, package adequacy, individual pattern quality, or first-entry publication. That cost is acceptable because those problems have different evidence and failure modes.

#Rationale

FPF carries transdisciplinary first-principles distinctions that can seed and discipline many domain and local frameworks. Those frameworks supply their own domain or local subjects and practices.

That makes FPF form a real architecture concern. Separate publication units, forms, exact presentation carriers, access routes, and the framework edition so adoption work returns authority to the subject patterns. E.4.DPF.DA answers the DPF package question; E.21 evaluates individual patterns; and E.2.DA evaluates whole-FPF adequacy.

#SoTA-Echoing

The current practical-entry declaration and the internal FPF quality, dependency, carrier, and access-route rules remain governed in Solution, checks, and Relations. They are not external SoTA evidence about this pattern. Official architecture-description references, current tool pages, fresh surveys, and lineage rows are omitted unless a future comparison shows the exact action-changing defect they are needed to expose.

#Relations

• Specializes: E.4 for the case where the framework family member under form work is FPF itself.
• Builds on: E.2 Pillars through E.2.DA for whole-FPF adequacy.
• Coordinates with: E.4.PFR when a named maintenance consumer needs a reusable relation, edition, dependency, publication, access, deprecation, or supersession record; otherwise state the direct relation assertion.
• Coordinates with: E.4.DPF and E.4.DPF.DA as sibling patterns for domain and local frameworks, not as FPF-level substitutes.
• Coordinates with: E.11.PFP for the common framework publication form and with E.11, E.17, and I.2 for first entry, projection, and publication or access use.
• Coordinates with: G.2, G.11, C.33, C.34, and C.35 for source, currentness, structural preservation, and generated or transformed carriers.
• Coordinates with: E.21, E.22, E.23, and E.9.DA when individual pattern quality, evaluation framing, improvement loops, or DRR adequacy provide evidence for FPF-level changes.

#E.4.FPF:End

#Principle-Framework Architecture Decision

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

#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

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

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 that performs it, 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 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 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.

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

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

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

#Domain Principle Framework Authoring and Publication-or-Access Carrier Assembly

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

#Problem frame

Use this pattern when a group needs to create a domain principle framework or local practice framework grounded in FPF: for example a hydroponic-cucumber framework, a neural-network architecture framework, or a Codex-process framework.

This pattern describes the reusable way of authoring or revising an FPF-grounded framework, not the files that happen to carry it. Start by writing one paragraph that names the intended reader, the domain or local situation, the first useful action, and the ordinary stop or wrong-turn return. Add a non-use boundary only when an independently grounded competing use is plausible for that reader and changes action. That paragraph is enough to enter the first-hour route before the framework architecture, durable names, or publication package are settled.

Use this pattern when the work creates or revises the framework itself. Use E.11 or E.17 when an existing framework remains unchanged and the work only changes how readers or agents find or access it.

#Problem

Domain and local framework authors often have strong source material and urgent local needs, but they can lose FPF discipline in three ways. They copy FPF terms without settling the domain ontology. They publish a framework carrier before deciding the framework architecture. Or they produce a useful checklist that is local process guidance but not yet an FPF-grounded pattern framework.

A working framework needs more than a good table of contents. It needs source-grounded pattern selection, architecture decisions, direct assertions of material relations, names, worked cases, quality evaluation, and refresh conditions. It also needs any relation or edition records required by a current maintenance use, including dependency, compatibility, migration, deprecation, or supersession when those uses are live.

A DPF gives an intended practitioner or assisting agent a source-grounded pattern language for recognizing typical problem situations in the domain, avoiding known failure modes, and applying SoTA solution moves with visible boundaries and refresh conditions. Its ontology and vocabulary support those moves. Known failure modes include beginner mistakes and experienced-practitioner failures caused by stale, local-only, or non-SoTA practice.

#Forces

#Solution

Start here with the cold-reader route. It answers whether framework authoring should begin before it asks for proposal, dependency, naming, quality, or publication apparatus.

1. Name the intended reader and recurring working problem.

2. State the useful move a domain or local principle framework might add.

3. Inspect what FPF Core, existing domain or local frameworks, and current sources already provide.

4. Test a cheaper search, curated reading route, or access-only result.

5. Before classifying the material by its carrier or a broad existing owner, recover candidate contributions as recurring practitioner problems, reusable moves or Methods, first useful results, ordinary stops or wrong-turn returns, and source or refresh boundaries.

   • Treat a role or competence account, several independently reusable contributions, a Card or mantra spanning material relations, a plausible field and refresh boundary, a representative use across contributions, or visible action or result loss under one broad owner as a cue to compare, not as proof of a DPF.
   • In one recognizable situation, compare each contribution with the exact current FPF or admitted-DPF action, first useful result, stop or wrong-turn return, and source or refresh obligation. Include a non-use boundary only when F.19's grounded-contribution test admits it. Preserve whether it is carried by an exact current owner, supplied by an exact external result, an action-bearing remainder, or unresolved. A shared topic, role label, carrier form, missing product name, or missing PatternIDs cannot close the question.
   • If this exact subtraction closes every contribution and no later-used field, edition, relation, direct-subject, publication, or access consequence remains, take the smallest useful result or stop. If exact ownership is unresolved, a coherent connected remainder survives, or closure would erase a material relation or field or refresh responsibility, keep the framework question open through the following steps.

6. If a reusable problem-solution language still looks useful, sketch one to four provisional pattern candidates with recognizable problems and solution moves. These candidates are seeds or contributions; their number does not make a framework edition.

7. State what field of practice the proposed framework promises to cover. Test whether its recurring problem families, pattern relations, and one representative first use need a new framework. If the current material is too narrow, retain it as, for example, a seed, a contribution to an existing framework, a guide, direct use of FPF and the sources, or another result whose direct kind fits its use.

8. Ask whether choosing among five outcomes—a new or revised framework, a contribution to an existing framework, a non-framework product, a thinner publication or access route, or no new maintained product now—will settle a later-used edition, dependency, initial pattern placement or relation, direct-subject identity or change rule, or publication or access decision whose rationale another author or reviewer needs.

9. If no, take the useful contribution, thinner route, other result, or stop without a DRR. If yes, use E.4.PFAD to state which of the same five outcomes was selected and its framework-specific consequences in one E.9 DRR.

These are alternative entry outcomes, not serial stages. A separate organization-design proposal is useful only when a named review use needs candidate organization claims. A separate dependency description is useful only when a named next authoring use needs a stable account of dependency availability and relevance. Neither is a prerequisite for recognizing or answering the architecture question. When a DPF answer is selected and authoring begins, grow the seed only as far as the next use requires: a source-pack stub; provisional public names; the first pattern candidates through E.8; ordinary assertions of the material relations among them; optional E.4.PFR rows for a named maintenance use; a publication or access consequence; and the first quality and currentness route. Add the effective ReferenceScheme, ClaimScope, qualification window, or a selected BoundedModelUseStructure only when those distinctions change interpretation for the receiving use.

Stop at the first useful result. A cheap route or stop needs no seed package. A rough DPF seed is inspectable when its reader, problem, useful move, source basis, provisional patterns and relations, edition/dependency boundary, publication or access consequence, and reopen condition are visible. Do not present it as a reliance-bearing DPF until the decision account is adequate for the intended authoring use, the pattern bodies are usable as normal FPF patterns, and the package is evaluated through E.4.DPF.DA.

Precision and object boundary after the first route. The first-hour route is Plain application guidance for one run-independent framework-authoring U.Method. This E.4.DPF episteme is a U.MethodDescription only because its EntityOfConcern is that independently admitted Method and its claims substantively describe how to carry it out under A.3.2; E.8 does not grant that membership. The Method, this description episteme, any U.WorkPlan, every dated authoring U.Work, and every result remain different objects.

If this account separately claims dated authoring or project U.Work, recover every precise performer's A.13 core and independently admit that Work through A.15.1. Cite F.6 only when the account also needs precise assignment-bound attribution through the same obtaining A.13 assignment. The complete tests remain in those patterns. The first-hour and complete authoring routes require neither a Work claim nor performer or assignment evidence.

The Work may use this description through an identified A.6.1 application and bindings. Recover any local system-role classification, capability, authority, responsibility, maintenance, access, Method, Work, or result claim through the direct pattern that defines it.

The first useful output closes the immediate question. It may be a cheap route or stop with no DRR; one E.9 framework-architecture answer selecting one of the five outcomes in steps 8–9; an optional organization-design proposal whose candidate claims need separate review; a post-existence architecture-description use; or an optional dependency description needed by a named next authoring use. These results are selected by their conditions, not by list order, and they do not form a mandatory lifecycle.

Choose the source route from the current question and the result it needs.

#Establish framework scale before edition authoring

Run the candidate-recognition move in E.4.DPF:4 before a public product name, PatternID, pattern body, or pattern count is available. One Card, file, admitted MethodDescription, role account, or absent PatternIDs neither proves nor disproves framework scale; each can only supply evidence for the same semantic test below.

Do not infer a new DPF or LPF edition from the current authoring slice. One useful pattern is usually a seed, candidate, or contribution, so pattern_count = 1 is a strong diagnostic: ask whether the candidate really supplies a connected pattern language rather than one useful result under a broad name. A few related patterns around one problem family may likewise form a useful selected problem-family pattern set inside an existing framework. In FPF, pattern nest remains the separate E.8 name for a publication and specialization placement grouping.

Run the same semantic test at every pattern count. A new edition needs a pattern language broad enough for its declared field or practice: a coverage map, selected problem-family pattern sets and material relations, a representative application, an internally usable first-edition set, honest omissions and source returns, and a credible edition, change, and refresh boundary. Fail a candidate when those contributions are missing or do not work together for the named first use, not because its index has one row. Adding a second thin pattern does not cure that failure, while an unusually compact candidate still has to pass every part of the same test. Before authoring a new edition, the E.4.PFAD architecture answer states:

• what field or practice the public name promises to cover, the intended reader, the first use, and the ordinary stop or wrong-turn return;
• the recurring problem families, characteristic failures, and useful result families that the first edition includes or deliberately leaves outside;
• the candidate selected problem-family pattern sets and the material relations among their patterns;
• one representative application that crosses the patterns and problem-family sets needed for the first use;
• the selected first-edition patterns, every same-framework prerequisite needed for that use, and every relied-on external edition;
• what the sources and evidence support, including whether each load-bearing claim is actual, proposed, or still untested, and what must be realized or tested before a stronger claim is made; and
• where each contribution goes: into the new edition, back to an existing FPF or DPF, into an LPF or another available result of its actual kind and supplying product, into direct source use, or into an explained decision to add no new maintained product now, together with the observation that would reopen the question.

Before placing a proposed narrower contribution, apply E.8:4.1.3 to it and the broader available contribution in one recognizable situation. Keep or merge a warranted difference that changes the reader's action or result; omit or merge a true duplicate; repair or reject an unwarranted difference. If something else answers the question, distinguish an available result from a MethodDescription, direct-source evidence, and an unavailable result; state maintenance only when it changes that use. This decides one contribution, not whether the package covers its public promise.

The first-edition set is internally usable only when it contains every selected pattern and every prerequisite from the same framework needed for the named first use. Keep relied-on results from an FPF, DPF, LPF, or separate non-framework product external when they are not members of this framework. For each external result, name the exact result and exact relied-on content, its direct kind, supplying product, exact edition or current state, receiving use, discovery route, and any currentness or availability condition that can change the use; say that it remains external. When the receiving use also needs a separate availability or compatibility result, name the exact result and exact basis on which it applies. When an edition dependency obtains, also name its direction, reason, and refresh condition. If these facts are missing or the result does not answer the promised use, keep the family as a gap or omission; do not hide it behind the word closed. When a keep, merge, removal, profile move, or external reliance 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 when that edition and its basis are unchanged; authoring history is not part of the D12 result.

Several sources may describe the same practice through structures that do not line up one-for-one—for example Methods, Work, subjects, descriptions, capabilities, providers, and cultural processes. When those differences affect the framework architecture, use C.32.MWA to produce one readable synthesis for the E.4.PFAD answer; that synthesis does not choose whether to create a DPF or another result. Use E.23.CDI only when the selected architecture includes developing capability for a named Work family, and use its result instead of copying its action sequence here.

When the DPF promises professional Method coverage, consume one exact accepted E.4.PFAD answer before treating a source list or pattern list as the authoring boundary. That answer already projects five connected claim groups from its compact eight-part answer; E.4.DPF consumes the projection and does not create a second input record. Keep the accepted answer, its accepting decision, the E.9 DRR, the later framework edition, and any publication carrier distinct.

The five groups remain recoverable by value, filled only to the grain that changes the declared first use:

1. Practice truth and first use: every bounded practice claim or promised practice contribution names its exact subject and scope and carries its own obtaining or possible-future status, practitioner, 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. The answer as a whole has no single truth-branch value.
2. Project and Method positions: 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. Incumbent Work, development or trial Work, candidate-practice Work, and intended Work keep different identities and truth status.
3. Selected structures and correspondences: 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: constraints, conflicts, failures, environment or interest changes, and observed, source-supported, estimated, contradicted, and missing links remain distinct from causal history and temporal unfolding.
5. Contribution, subtraction, gaps, and reopen: 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 accepted answer may therefore carry an obtaining incumbent-practice claim beside a possible-future candidate-practice claim. Every selected question and resulting authoring disposition points to the exact bounded claim or claims it consumes. An independently obtaining A.13 agency claim, actual incumbent Work, or actual development or trial Work keeps that status without making candidate-practice Work or candidate-practice coverage obtain. Public coverage is asserted separately and only at the scope and truth status supported by the exact edition and its evaluation.

For an obtaining practice claim, name actual recurring difficulties and representative actual Work. When the claim relies on a precise Agent performer, recover the A.13 core: exact admitted System, local agential kind and criterion, classification, obtaining assignment, and needed scope, working situation, and window. Add an 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 actual Work from its performance history, Method, extent, and containment; only after admission does F.6 add any precise assignment-bound attribution through that same assignment. A missing F.6 relation leaves Work membership intact and the attribution unresolved. State the evidence limits.

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. Do not invent past candidate-practice Work, actual candidate-practice Agents, or an obtaining candidate practice. Before the trial, the honest public claim is prospective guidance or architecture for the bounded trial, not current candidate-practice coverage.

Turn the accepted input into one bounded authoring disposition for every selected question. Name the receiving pattern, the exact bounded practice claim or claims consumed, and the domain Method, evidence, constraint, direct relation claim, obtaining case, or planned trial still needed; or return an honest seed, external result, gap, omission, or reopened architecture question. If the PFAD answer omits a required group or claim-to-question binding at the grain needed by first use, return that bounded PFAD gap instead of inventing the value. One clear question stays with its subject pattern. Use C.32.MWA only when correspondences or conflicts among several selected structures change the answer, and use its completed result rather than copying its action sequence.

E.4.DPF.DA evaluates the resulting exact edition once. D1DomainScopeAndUseAdequacy preserves the reader, first use, stop or return, qualification window, truth boundary, and any locally warranted non-use boundary of every public practice contribution. D4CoreDependencyAndDomainBoundaryAdequacy tests FPF subtraction, domain filling, and exact external dependencies. D5PackageFormLayeringAndRelationAdequacy keeps answer, accepting decision, DRR, edition, package, publication, and carrier separate. D7PracticeUtilityAndProblemResolutionAdequacy uses the recognizable difficulty, practical move, and receiving result for each bounded claim without upgrading observed, planned, or missing evidence. D8HeterogeneousCaseAndTransferAdequacy uses a representative obtaining case or planned prospective trial and preserves its transfer boundary. D11DomainSoTAAlignmentAdequacy uses current domain sources, pressure evidence, limits, and reopen triggers. D12DomainProblemFamilyCoverageAdequacy alone integrates the exact edition's several bounded public promises while retaining their different truth status; it cannot turn a prospective contribution into current practice coverage or erase an obtaining incumbent contribution.

The same case or source may support several coordinates, but each coordinate is judged once in the D1-D12 aggregate. Do not add a second project-Method architecture checklist, proof-of-revisit requirement, or second pass over the same evidence. The input can be compact prose and a few selected structures. It is not a universal record schema, fixed view set, mandatory diagram count, source-chapter destination map, project lifecycle, or proof that a Method works or transfers. If no accepted answer identifies which practice questions change first use, or a required domain filling is missing, keep the affected contribution as a seed, gap, or omission and return to the exact E.4.PFAD or domain-source question. Do not infer Method parthood from a required contribution, transformation, Work enactment, capability, provider contribution, or cultural change merely because a source lists them together. Keep the mapped objects distinct. A Method may be described by a MethodDescription, and a pattern may contain such a description only when A.3.2 applies. Selected patterns and their material relations make up the pattern language; a framework edition contains one version of that language; an exact U.PresentationCarrier may bear a selected publication or access-facing form; and an access route may help a reader or System reach the edition or a named carrier. Publication, availability, and actual access remain separate claims. Conceptual synthesis may support a candidate architecture or distinction, but it is not evidence that a Method works or transfers.

Use product here only as Plain management wording for a deliberately identified result or service boundary. It helps a team state intended use, identity or current state, access, later change and retirement rules, and any maintenance that actually obtains. 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, publication, availability, or maintenance. Constitution or publication establishes only the claims made by those acts; maintenance and future Work need their own evidence. If the direct kind or relation is not settled, keep the management boundary as a proposal and return that question instead of inventing a common object kind.

A framework edition is an exact episteme. Treat its Readme, Preface, ToC, pattern bodies, 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, and change rule. Being outside the pattern set or in another file does not by itself create another product or a maintenance claim.

Make a separate adjacent product only when people need to change, cite, or use 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 later-review or retirement rule, or cross-framework reuse or reliance. A separately established maintenance relation may also matter, but product identity does not require it. A registry, guide, evidence package, companion, catalogue, tool reference, access service, programme, or another direct subject may justify that boundary; the label does not settle the subject kind. When the direct subject is independently used or changed, 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.

When programme is used, start with what actually continues. If a subject pattern admits the programme as a System or another exact arrangement, name it. Otherwise name the current programme-description episteme and any provider System, maintenance relation, accepted commitment, or service state that independently obtains. 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.

A combined presentation carrier stays neutral. Each constituent keeps its own identity, edition or state, form, access, later-change and retirement rules, and any separately established maintenance relation; the outer navigation names the exact constituents. Apply E.11.PFP only to FPF, DPF, or LPF constituents. An adjacent non-framework result uses the form and indexing discipline selected for its direct kind. DRRs, build manifests, quality runs, digests, logs, and campaign state remain process or maintainer evidence unless a selected reader use gives a direct subject its own product identity and publication or availability route. When recurring domain wording prevents reliable use of the DPF patterns, apply the shared restoration method in E.10.ARCH and keep the domain entry beside the patterns that use it. Identify a separate local profile only when several entries have a named maintained use; if a table publishes the profile, keep the table as its publication form. A DPF with no demonstrated recurring wording problem needs neither.

Use E.4.DPF for the authoring route and its optional proposal or dependency branches, E.4.PFAD for framework-decision content, E.8 to author patterns, and E.4.PFR only when a named maintenance use needs a relation or edition record. Use E.11.PFP for the common framework publication form, E.24.PUB for publication occurrence, form, carrier, audience, bounded use, availability, and access, E.11 for practical entry, and E.17 for a source-backed publication face. Use E.4.DPF.DA and E.21 for package and pattern evaluation, E.23 for improvement, and G.11 for currentness. Each result or relation follows the predicate and evidence in its owning pattern. If one receiving use genuinely needs reusable conditional unfolding, select one exact A.22.CGUS ConstraintGovernedUnfoldingStructure separately from this MethodDescription. Recover its A.22 identity, separately identified constituents and obtaining relations, applied constraints, more than one admissible continuation, and explicit stops or returns; keep any demonstrative walkthrough as a separate C.2.1 episteme. Otherwise keep the route Plain.

When separately admitted dated authoring Work first constitutes a framework episteme or a revised framework episteme, recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is also current. Recover the local inception claim separately through A.15.PROD. C.2.1 identifies each authored framework episteme by its ClaimGraph, EntityOfConcern, and effective U.ReferenceScheme. An obtaining EpistemeEditionRelation, the authoring change or inception claim, the package architecture, and any EpistemePublicationRelation remain separately revisable. Publication occurrence, publication form, presentation carrier, framework truth, edition continuity, and package membership use their direct predicates and evidence.

The complete authoring account keeps the domain or local use frame, source basis, selected architecture, names, pattern drafts, direct assertions of material relations, publication or access, quality, improvement, and currentness returns recoverable. Keep any relation or edition records required by a named maintenance use recoverable too, without turning their order into another object.

When the selected architecture answer is to create or revise a DPF and authoring begins, keep claim-bearing epistemes, publication forms, presentation carriers, and access routes separate. Keep the accepted answer in a developer decision carrier written with the E.9 decision-record method and checked by E.9.DA. It carries the source basis, selected architecture answer guided by E.4.PFAD, initial pattern split and direct assertions of the material relations among those patterns, publication or access consequence, alternatives, rationale, consequences, first action, and reopen condition. Publish the user-facing framework through a carrier named for the individual framework, either as one assembled form or as a split set of publication units. An exact access-facing artifact is a U.PresentationCarrier only when it bears the selected form; identify the service or route through which readers reach it separately. Keep a source pack, E.4.PFR record, quality result, package evaluation, access manifest, or service description separate when its independent use and change require that boundary. C.2.1 framework-episteme identity, EpistemeEditionRelation, package architecture, E.24.PUB publication occurrence, form, presentation carrier, access route, and actual access or use remain distinct; process state remains outside the user carrier. A cheap route or stop remains outside this arrangement; its result is the route or stop itself.

Plain vocabulary for adoption:

Old intake labels such as SPF, TPF, or broad xPF, and the strings FoundationalPrinciplePatternSet and ZPF, remain source aliases until F.18 settles a durable public name and any admissible short form. Use the full descriptive phrase "foundational principle pattern set" when that subject must be described before naming is settled. If an alias suggests a different framework identity, open the F.18 naming question before public use.

Keep the authoring apparatus proportional to the next receiving use. A first exploration may stop with a cheap route or no-framework answer and no decision record when it settles no later-used framework boundary. A compact reliance-bearing framework may keep its readme, preface, pattern bodies, relation rows, source-use account, and quality route in one carrier when the same readers and stewards maintain them together. Split source packs, decision records, relation records, pattern files, quality results, skills, or access services only when independent editioning, confidentiality, transfer, automation, delayed feedback, expensive reversal, or another named reliance makes their identity separately useful. Create an organization proposal only when candidate organization claims need separate review; create an authoring-dependency description only when a named next use needs stable dependency availability and relevance. More files or records do not make the framework more mature.

Prompt-shaped starter for SoTA harvesting and first candidate generation:

Help draft a first FPF-grounded principle-framework candidate.

Domain or local situation and semantic boundary: effective ReferenceScheme, ClaimScope, qualification window, and optional selected BoundedModelUseStructure only when interpretation depends on it:
Intended reader and first use:
Independently grounded non-use boundary, only when the full F.19:4 test warrants it: a plausible intended reading, changed truth, understanding, or use, and the smallest clear correction:
Selected source basis and why it fits this question: direct source | maintained synthesis or guide | bounded F.1/F.0.2 route | existing G.2 pack | earlier DPF | derived lookup
Source traditions to inspect:
Rival traditions or schools not to lose:
Local examples or internal sources:
Earlier DPF pattern or claim reused, kept local, or proposed as an FPF improvement:
Derived-lookup coverage, authoritative return, and unresolved source needs:
Adopted source payload to carry into pattern solutions:
Rejected source payload and why rejected:
Recurring domain wording whose repeated misreading needs a local E.10.ARCH entry, if any:
Recurring domain or local problem situations and forces:
Reusable solution moves and consequences:
Candidate first patterns, each with problem frame, positive solution, worked slice, and local anti-pattern:
Field or practice promised by the public name, intended reader, first use, stop or wrong-turn return, qualification window, and any independently grounded non-use boundary:
Recurring problem families, characteristic failures, useful result families, selected problem-family pattern sets, material relations, and honest omissions:
Representative application crossing the patterns and problem-family sets needed for first use:
Professional Method coverage, when it changes the answer: the practice questions selected by `E.4.PFAD`, the pattern used for each, the domain content needed, and whether `C.32.MWA` is required because several structures do not line up one-for-one:
Whether capability development for a named Work family makes `E.23.CDI` current:
Patterns included in the first edition and same-framework prerequisites needed for first use:
External FPF, DPF, or LPF editions: exact relied-on content, use, direction, reason, refresh, and any required availability or compatibility result with its exact basis:
Which load-bearing claims are actual, proposed, or untested, and what must be realized or tested before stronger use:
Destination or source return for every contribution not selected into the framework edition or another named result:
Candidate relation functions among the patterns:
Current first result and selection condition: cheap route or stop with no DRR | one open architecture question answered by a new or revised framework, a contribution to an existing framework, a non-framework product, a thinner publication or access route, or no new maintained product now in an E.9 DRR | optional organization-design proposal | post-existence architecture-description use | optional authoring-dependency description

Dependency on FPF Core or a domain framework edition:
Publication form and exact presentation carrier for first use; access route if one is needed:
Quality route: which first drafts should be evaluated and improved:
Refresh triggers: source change, Core edition change, local-use telemetry, or policy change:

Return the current result and only the adjacent source, naming, pattern-draft, relation, publication or access, quality, and currentness notes that its receiving use needs. If the result is a cheap route or stop, create no framework-decision record. If the requester wants a ready DPF rather than a seed, keep the E.9 DRR or decision carrier separate from the user DPF publication form, exact presentation carrier, and any access route, then name which `E.21`, `E.4.DPF.DA`, and currentness checks remain before reliance.
Do not present generated text as authoritative. Before relying on it, name the unresolved claims and the contribution still needed: direct source return; a relevance-based source cut through `F.1`; a bounded conceptual-synthesis result through `F.0.2`; an optional broad `G.2` pack; authoritative return and partial-failure handling for a derived lookup; carrier typing from `C.35`; framework-decision profiling from `E.4.PFAD`; an optional relation or edition representation from `E.4.PFR`; local wording restoration through `E.10.ARCH`; naming from `F.18`; quality evaluation from `E.21`; or a currentness check from `G.11`.

1. Domain or local use-frame declaration. State the intended reader, first use, stop or wrong-turn return, effective ReferenceScheme, ClaimScope, qualification window, and any non-use boundary admitted by [F.19](/generated/patterns/F.19)'s grounded-contribution test. Select a BoundedModelUseStructure only when its exact organization changes interpretation for this receiving use. Record each of these values through its direct pattern and predicate.
2. Source basis and synthesis route. Select the applicable branch above. Use direct source reliance when one claim is enough; [F.1](/generated/patterns/F.1) when source selection alone is current; [F.0.2](/generated/patterns/F.0.2) for one bounded comparison across source ontologies; and [G.2](/generated/patterns/G.2) only for the broad CG-Frame pack and its downstream handoffs. Resolve derived lookups to authoritative editions, treat non-return as partial coverage, and classify earlier-DPF material as direct reuse, a receiving-DPF claim, or a proposed FPF improvement. Record adopted and rejected source payload, examples, currentness, and reopen conditions in the DPF source-use account.
3. Cheap exit, optional proposal, or architecture answer. First test whether current FPF and sources close the immediate use through a cheaper route or stop without settling a later-used framework boundary; if so, stop without a DRR. Create the C.2.1 organization-design proposal described in 4.2–4.4 only when a named review use needs candidate organization claims. When a later-used boundary makes the architecture question current, use [E.4.PFAD](/generated/patterns/E.4.PFAD) to profile one [E.9](/generated/patterns/E.9) DRR and select one of the five outcomes named in the first-hour route. If the answer selects a new or revised framework, state what field it promises to cover, its coverage map, representative application, first-edition set, external dependencies, omissions and returns, and which load-bearing claims are actual, proposed, or untested. Treat a one-pattern candidate as a strong warning and run the same framework-scale test used at every count. If the candidate lacks connected problem-family coverage, material pattern relations, a representative application, an internally usable first use, or a credible edition, change, and refresh boundary, keep it as a seed or contribution; the count itself does not decide. Keep the selected answer, acceptance, DRR, package architecture, direct relation assertions, any relation or edition records required by a named maintenance use, edition dependencies, authoring, and any ADR-like publication distinct.
4. Name and wording preparation. Use [E.10](/generated/patterns/E.10) for kind discipline and [F.18](/generated/patterns/F.18) for durable names before public pattern heads or abbreviations stabilize. When a recurring domain wording failure blocks use, apply [E.10.ARCH](/generated/patterns/E.10.ARCH) to write a local entry beside the affected DPF patterns; create a separate profile only for a named maintained multi-entry use, and keep any table that publishes it as a publication form.
5. Carrier admission. Use [C.33](/generated/patterns/C.33), [C.34](/generated/patterns/C.34), or [C.35](/generated/patterns/C.35) before relying on all-in-one carriers, tables of contents, relation graphs, source summaries, search outputs, transformed views, or generated candidates as architecture evidence.
6. Pattern drafting. Draft patterns with [E.8](/generated/patterns/E.8): recognition text, positive solution, worked cases, boundary, local anti-patterns, SoTA-Echoing, conformance checks, and relations. E.8 supplies authoring and publication-form rules; it does not make every pattern episteme a U.MethodDescription. Apply A.3.2 only when the episteme has one independently admitted Method as its EntityOfConcern and substantively describes how that Method is carried out. In a DPF, the pattern bodies render selected domain or local problem-situation architecture and solution-move architecture. When repeated first use benefits from an attentional aid, write a Plain local mantra by compressing that pattern's Solution without dropping the distinction that makes the move work or the stop, return, or redirect condition. Keep an established local name such as mnemonic, watchword, or heuristic when it explains the aid better. Use [A.22.CGUS](/generated/patterns/A.22.CGUS) only when an independently selected ConstraintGovernedUnfoldingStructure has exact constituents, obtaining relations, constraints, admissible continuations, and stops; keep its demonstration separate. A thin skeleton, prompt seed, compressed design note, or memorable slogan detached from the Solution remains a pattern seed until an [E.21](/generated/patterns/E.21) evaluation finds the pattern adequate for the declared DPF use.
7. Relation and edition discipline. State each material relation directly with its defining predicate. Use [E.4.PFR](/generated/patterns/E.4.PFR) for a relation or edition record only when a named maintenance use needs that representation. When dependency, compatibility, migration, deprecation, or supersession is current, keep the corresponding record recoverable.
8. Quality cycle. Use [E.22](/generated/patterns/E.22) to frame the evaluation purpose, quality floor, trade-off question, and expected improvement proposal when that frame is not already scoped. Use [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) to evaluate the package as a DPF or local-framework package, [E.21](/generated/patterns/E.21) to evaluate individual pattern quality, [E.23](/generated/patterns/E.23) for repeated improvement, and [E.19](/generated/patterns/E.19) only when admission or profile gating is actually being claimed. If an evaluation result needs a carrier, publish or refresh that carrier through the pattern that defines its publication or currentness relation rather than through [E.22](/generated/patterns/E.22).
9. Admission review. Use [E.19](/generated/patterns/E.19) when the local process asks whether a pattern or framework slice is ready for admission.
10. Support-unit and adjacent-product boundary. Use product only as the Plain management umbrella defined in E.4:4.1. Group framework publication units only when they share the framework edition, declared readers and use, edition boundary, access, and change rule. For every proposed adjacent result, name its direct subject and test independent use and change, identity or current state, an intensional rule for what belongs, access, any later-review or retirement rule that changes use, and cross-framework reliance. State maintenance separately when it obtains. Keep ordinary framework material as a support publication unit; keep an independently useful subject separate and point to its exact edition or state. Treat shared use and a combined carrier only as boundary probes.
11. Framework publication-carrier assembly and access-route check. Expose the selected framework episteme edition through exact publication and access relations. An exact form-bearing artifact is a publication- or access-facing U.PresentationCarrier; identify the service or route through which readers reach it separately and name any returned carrier. When a Markdown carrier bears a publication containing the full [E.8](/generated/patterns/E.8) pattern bodies, use [E.11.PFP](/generated/patterns/E.11.PFP) for the common reader-facing title and edition cue, one logical index, and one practical-entry set with five-field ordinary entries and six-field selected cards. Show authorship, date, dependency, language, access, or a product-declared maintenance status, support window, or currentness window in the opening only when a product-specific publication rule names the reader decision or action they change. Keep the FPF heading hierarchy in that publication: the framework title and major publication units or Parts are H1, each PatternID and pattern title is H2, each canonical [E.8](/generated/patterns/E.8) section is H3, and each nested section is exactly one level deeper. Navigation may surround a body, but it must not demote the body or merge two source heading levels. Keep the E.11 first-entry publication functions recognizable: in English use Table of Contents, <framework name> Readme, and Preface, and translate them consistently in another publication language. Do not create a parallel Pattern Index for the same ToC function or rename the Readme Reader Guide. Generated-source comments, source paths, source-set digests, machine identity blocks, build commands, and do not edit markers remain builder, package, manifest, or maintainer evidence rather than reader front matter. A compact card or summary remains entry guidance, while a genuinely distinct index remains a finding aid. Each returns to the ToC or Readme that locates its full pattern body, or directly to that body; do not present it as that body. After assembly and before calling the carrier released, current, or ready for its declared use, inspect the assembled carrier rather than only its sources: use the [E.11](/generated/patterns/E.11) practical-use carry-through check for the public entries and [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) for package form, preservation of the published pattern bodies, and declared use. A successful build run shows that generation succeeded; it does not show that the published hierarchy, entry route, or pattern content survived. Under E.24.PUB keep publication occurrence, selected episteme edition, audience declaration, bounded-use declaration, publication form, and presentation carrier distinct; use the direct access pattern for actual access or use. Framework identity, package membership, truth, Work authority, and landing use their direct predicates and evidence. Domain or local frameworks publish through their own selected carriers.
12. Currentness route. Use [G.11](/generated/patterns/G.11) for refresh plans, edition pins, source decay, deprecation, and supersession conditions.

Localize each repair before returning to wider framework architecture. A changed source payload first reopens the direct source use, F.1 source cut, F.0.2 comparison, or G.2 pack actually used, and then only the dependent assertions, examples, or relations. A changed Core or depended-on framework edition first updates the affected [E.4.PFR](/generated/patterns/E.4.PFR) dependency, compatibility, and migration relations. Repeated misuse of one pattern first reopens that pattern's [E.21](/generated/patterns/E.21) result and its [E.23](/generated/patterns/E.23) improvement loop; a repeated domain wording failure may also reopen its local [E.10.ARCH](/generated/patterns/E.10.ARCH) entry. A failed publication or access route first requires [E.11](/generated/patterns/E.11), [E.17](/generated/patterns/E.17), or the carrier relation that exposed it. A local mantra that no longer preserves its pattern Solution requires comparison with the exact Solution in that pattern body; [A.22.CGUS](/generated/patterns/A.22.CGUS) becomes current only if the repaired aid must present a wider conditional unfolding. Use [E.4.PFAD](/generated/patterns/E.4.PFAD) only when the evidence changes selected framework-family, pattern-split, relation-structure, publication-form, presentation-carrier or access-route architecture, or dependency-boundary decisions. Use [G.11](/generated/patterns/G.11) when edition currentness, source decay, telemetry, deprecation, or supersession must be orchestrated across those local repairs.

For an all-in-one DPF publication carrier, assemble the content in a reproducible order. This order is a publication shape, not a new framework kind. In an all-in-one Markdown publication that contains the full pattern bodies, the framework title and major publication units or Parts use H1, pattern bodies begin at H2, and their canonical sections begin at H3. The framework name and publication language may vary with the domain and readers; [E.11.PFP](/generated/patterns/E.11.PFP)'s reader-facing sequence, pattern-row profile, publication-unit jobs, and the heading hierarchy do not. In English label those functions Table of Contents, <framework name> Readme, and Preface; use one consistent translation in another language:

1. Public framework title: use a domain- or practice-specific framework name such as <DomainOrPractice> Principles Framework; Principles Framework alone is only the head or kind phrase, not an individual framework name. Do not put local monolith, draft, process status, or file-layout slang in the public title.
2. Short public edition line directly under the title: name the stable public edition designation and a public edition-record locator. Add a dependency, language, access, product-declared maintenance status, support window, currentness window, or other short cue there only when the product-specific publication rule names the reader decision or action it changes. Do not create a separate edition H1 or put a machine identity block, source digest, source path, or build marker before the ToC; keep detailed edition and relation records after the pattern bodies or in maintainer evidence.
3. Table of contents: place one search-oriented overview before the body collection and use [E.11.PFP](/generated/patterns/E.11.PFP)'s five-position pattern-row profile. Every pattern row exposes its PatternID and title and gives at least one recognizable working-question cue in Keywords & Search Queries. State the DPF's declared reference code and local-locator form where a reader can disambiguate citations. Keep the displayed § position separate from PatternID; the current row order may be non-ascending by PatternID but must match the body order. Use Status and Dependencies for values that can change the reader's choice; do not copy first move, result, and boundary into additional mini-method columns. Pattern bodies remain the main language of use; support maps and any relation or edition records required by current maintenance remain reachable without becoming a universal first inspection sequence or prescribed use order.
4. Framework Readme: for the intended reader, present recognizable first-entry situations and practical questions, the first useful result or honest blocker, the direct pattern or small plausible set, the ordinary stop or wrong-turn return, and any non-use boundary admitted by [F.19](/generated/patterns/F.19)'s grounded-contribution test. State briefly which selected domain or local structures this carrier exposes.
5. Preface or framework context: cross-cutting ideas that make the pattern set cohere, plus the selected structure families the carrier foregrounds, deliberately coarsens, defers, or sends back to sources and pattern bodies.
6. Package carrier structure-account: intended reader and use, selected source-structure denominator, recurring problem-situation structures, reusable solution-move structures, captured structure, deliberately coarsened, abstracted, omitted, or lost structure, source-return condition, and quality or epiplexity route. This may be a short subsection in the Readme or Preface when the carrier is compact.
7. Package boundary and subject-pattern routing: Core subject patterns reused, local terms bounded, and source, evidence, assurance, publication, and refresh exits named.
8. Pattern bodies: each drafted through [E.8](/generated/patterns/E.8), with its PatternID and title at H2, canonical sections at H3, and deeper sections retaining their relative levels; each carries recognition text, positive solution, worked cases, local anti-patterns, SoTA-Echoing, conformance checks, and relations, and each is evaluated or explicitly marked as a seed under [E.21](/generated/patterns/E.21) before the package is claimed for public, teaching, enterprise, or reliance-bearing use.
9. Heterogeneous acceptance cases or transfer probes: examples that force the pattern set to work across unlike uses rather than only repeating the motivating case.
10. Support maps or appendices: architecture bridge, source-use map, precision map, package-name route, or other reference material placed after pattern bodies unless a short first-entry trigger table is needed.
11. Source use and refresh map: source rows with adopted payload, rejected or bounded readings, the conditions that reopen a direct source use, F.1 source cut, F.0.2 comparison, or optional G.2 pack, and the conditions under which source currentness or refresh must be reconsidered with [G.11](/generated/patterns/G.11).
12. Conditional relation and edition records: add [E.4.PFR](/generated/patterns/E.4.PFR) rows only when a named maintenance use needs a stable representation of dependency, specialization, publication, source reuse, evaluation, generated-carrier, teaching publication-carrier, ethics, deprecation, supersession, or edition effects. Otherwise keep the direct assertion.
13. Refresh dependencies: which source-use, pattern-quality, package-adequacy, edition-dependency, or publication-carrier claim must be reopened when source, Core edition, local use, telemetry, or evaluation changes. Every DPF publication or access-facing U.PresentationCarrier named here bears a selected form; an access route may help a reader or System reach the edition or a named carrier, but it does not bear the form or establish availability or actual access by itself. In an all-in-one publication carrier, the Readme and Preface usually carry the first explanatory route, and sometimes a narrative rendering, through the domain. Their representation relation remains inspectable when they say what they are telling, for whom, which structures they foreground, which structures are deliberately coarsened, abstracted, omitted, or left to source return, and where a reader returns for fuller pattern, source, evidence, or relation detail. This is not only text-to-text summarization: the source-bearing side may be actual or possible holon structure, an architecture description, a view, a source pack, a model, a graph, or a pattern set. In architecture-mediated narrative-rendering use, read the return chain as narrative rendering borne by an exact presentation carrier -> architecture description or view -> architecture as selected structures under its exact use frame -> wider source structures. When no narrative rendering is present, read the first step as selected publication form borne by an exact presentation carrier -> selected source structures. If entry begins at an access route, name the first form-bearing carrier or response reached and follow the same chain. Each step states selected structure, captured structure, coarsening, abstraction, omission, loss, and return conditions. An architecture description is often already a coarsened representation of selected real, expected, candidate, or actual structures, so the DPF carrier keeps that second-step loss visible. This does not make every DPF a literary narrative or every carrier a narrative. When a sequential narrative rendering is load-bearing, use [A.6.3.NAR](/generated/patterns/A.6.3.NAR); when the publication expression deliberately keeps only a narrower-use coarsened rendering, use [A.6.3.CSC](/generated/patterns/A.6.3.CSC); for structure capture and loss, use [C.33](/generated/patterns/C.33); for same-enough or preservation claims, use [C.34](/generated/patterns/C.34); for practical-use publication and access, use [E.11](/generated/patterns/E.11), [E.17](/generated/patterns/E.17), and the direct publication or access pattern; for package adequacy, use [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA).

Keep process and build state out of the carrier. DRR text, handoff notes, ledger rows, review status, helper state, admission blockers, landing evidence, generated-source comments, source paths, source-set digests, and build instructions may shape or identify the package, but the publication carrier should contain only durable user-facing package content, source-use boundaries, relation records, quality routes, and refresh conditions. A short source-use or relation record may appear in the user carrier when it helps readers and maintainers use the DPF; a DRR argument, review transcript, quality proof, or build manifest does not.

For access-facing carriers and routes, keep the same framework edition identity, direct relation assertions, and any relation or edition records required by current maintenance visible. An exact artifact is a U.PresentationCarrier when it bears the selected access-facing form. A service or other access route names any returned carrier separately. When an implementation uses a skill pack, MCP service, endpoint, retrieval or search route, or assistant integration, classify it through those same predicates. If the route generates candidate text, use [C.35](/generated/patterns/C.35); if it performs Work or triggers tools, use [A.15](/generated/patterns/A.15) and the pattern that defines the local tool or Work relation; if it claims currentness, evidence, assurance, or decision authority, use [G.11](/generated/patterns/G.11), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [E.9](/generated/patterns/E.9), or the pattern that defines or tests that claim. Take the DPF architecture from the accepted architecture answer and the framework episteme. Use [E.4.PFR](/generated/patterns/E.4.PFR) only when a named maintenance use needs a stable relation representation.

Starter evaluation characteristics for a principle-framework improvement loop:

These are evaluation characteristics for selecting and framing improvement Work. They are not measurement programs by themselves. If the pass needs a DPF package adequacy result, use the predicate defined in [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA); if it needs individual pattern quality, use [E.21](/generated/patterns/E.21); if it needs DRR adequacy, FPF-level Pillar adequacy, measurement, evidence, or architecture-characteristic evaluation, state the exact subject assertion and use [E.9.DA](/generated/patterns/E.9.DA), [E.2.DA](/generated/patterns/E.2.DA), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), or the relevant architecture-characteristic pattern only as the locator for its definition or constraint.

This episteme's A.3.2 MethodDescription use and its result-and-use account are sufficient only when a reader can answer: which framework episteme edition is being authored; what problem-and-solution architecture it renders; which sources and decisions shaped it; which patterns and material direct relations were selected; which relation or edition records a current maintenance use requires; which publication occurrence, form, carrier, or access relation exposes it; how quality improves; and when it returns for refresh or repair. If the account also claims dated Work or a result relation, identify that claim through its direct pattern; E.4.DPF requires neither claim merely to describe the authoring Method.

#Return suite and guide proposals to their own decisions

Suite constitution and each inclusion or removal are separate decisions under E.4:4.2 and E.4.PFAD. Belonging states collection membership between one DPF product series and the Suite. State field coverage, edition adequacy, dependency or compatibility, maintenance, publication or access, recommendation, and Guide use through their own direct predicates and grounds. A shared carrier, Guide entry, author, or locator may report membership but does not establish it.

An author may propose that a DPF product series join or leave a Suite, or that a Guide entry use one of its results. Keep inclusion and removal as proposals until the Suite decision takes effect. Return those proposals to E.4:4.2 and E.4.PFAD, where the ecosystem purpose, the rule for which product series may belong, inclusion and removal rules, identity through change, later review and retirement, and exposure are decided; state maintenance separately when it obtains. Keep a proposed Guide entry separate until the Guide product's content or refresh decision selects it. Make and check the entry's direct claims about DPF results and sources under the patterns that define those claims. A state with one product series or none follows the Suite's explicit preservation, restoration, review, or retirement rule; a DPF edition does not decide that state from inside itself.

For a dependency, name the dependent and relied-on editions, relied-on content, receiving use, and invalidation or reopen fact. For compatibility, name the edition pair, overlapping use, difference or interface, impact, and reopen condition. Until those facts satisfy E.4.PFR, keep the proposed use, constraint, or question. Suite belonging and Guide navigation report their own collection and navigation claims. The current FPF treats product series and the Suite as continuing collections; the complete A.1 test remains the route for any holon or constructive-part claim.

#Select practical examples for the product

Before shaping a DPF or LPF Readme, distinguish three jobs. A compact locator points to a direct pattern when retrieval is enough. An ordinary practical entry shows how one direct pattern or one bounded direct route can answer a comparatively simple difficulty without a mantra. A Practical-Use Card is selected only for a recurring complex difficulty when a repeatable formula materially helps the reader retain a useful path through several direct pattern contributions, checks, and returns.

Apply the E.11 comparison to the same truthful content with and without a mantra. If the reader can choose, obtain the first result or blocker, and return just as reliably without it, keep the locator or ordinary entry. Do not infer card form from pattern count, heading depth, phrase length, an inherited label, or a desired quota. Do not avoid the comparison by calling a rich cross-pattern example ordinary.

Keep one declaration for the product. It assigns every selectable example key exactly one ordinary-entry or card form. When the product selects cards, the declaration gives one measurable reading-burden rule plus mantra and compact-card maxima. Authors, builders, and validators use that same declaration and the shared visible grammar from E.11.PFP. A product may select no cards when locators, ordinary entries, or direct guide answers already support reliable choice and return; it then carries no card-form burden.

Use examples selected for that product's readers and recurring questions. Say plainly that they are not a catalogue or coverage boundary and return unmatched questions to the product's index, guide, search, or direct patterns. When both simple direct use and extended cross-pattern use matter to adoption, show representative examples of both without turning every useful topic or pattern set into an entry. Do not copy the FPF key inventory, card count, whitespace-token limits, or optional @FPFReadme records, and do not create a rival local card grammar or second key registry. Keep a pattern-local mantra used to recall one pattern's Solution, a Readme card mantra used to retain a longer cross-pattern path, and an independently admitted CGUS demonstration distinct. Claims about a Method, performed Work, project result, or stronger relation use their direct patterns and evidence.

#Keep pattern addresses stable while publication order changes

Before public references accumulate, declare a short, stable code for the DPF and assign one local locator to each pattern. Together the DPF code and local locator form the PatternID. Within that DPF, each PatternID is unique. The code is only a short reference to that named DPF; it need not be globally unique and does not identify an edition. Settle a new durable public abbreviation through F.18. If the public DPF code later changes while the same DPF continues, preserve old references through an explicit F.13/F.18 rename or alias relation and a reader return; otherwise say where old-code use stops. Do not silently rewrite old citations. Do not assign the old code to another framework where readers may encounter both sets of citations without the full framework name.

A PatternID lets readers refer to a pattern carried forward across editions. The identifier does not prove that two bodies are the same pattern and does not define the pattern's claims. Keep it while the recurring problem, distinguishing working move, useful result, and ordinary conditions for use, stopping, or returning still describe the same practical answer. A title, wording, Part, publication position, or authoring work package may change while that answer continues. A PlannedCatalogEntry may reserve an unused locator, but it is not yet an addressable PatternRef or evidence that a continuing pattern exists. When a complete pattern is admitted and published, its author may adopt that locator as the pattern's PatternID. The publication may use it as a PatternRef only after the complete body exists and the continuity judgment has been made; the reservation alone establishes neither identity nor addressability.

When the practical answer no longer continues, decide the split, merge, replacement, or retirement explicitly. Keep an earlier PatternID only for the answer that continues. Give each new pattern a new unused PatternID, and never reuse a retired PatternID for unrelated content. If readers still use an old public reference, publish one maintained migration assertion. It names the earlier PatternID, any current PatternID or PatternIDs, whether the practical answer continued, split, merged, was replaced, or was retired, the uses covered, and where readers continue or stop. Add a structured E.4.PFR row only when a named maintenance use needs it; otherwise the readable assertion is enough. If no migration assertion is maintained, say where use must stop.

The local locator may use the numeric or mnemonic segments allowed by E.8. Prefer a numeric locator when it mainly needs to remain a durable address among many peers. Use a mnemonic segment only when it names an enduring distinction likely to outlast the title and publication position and materially helps recognition. A mnemonic is still an address aid, not a compressed definition. Do not restyle established PatternIDs merely to make the set look uniform.

Keep current publication order separate. The ToC and body collection use the same Parts and the same within-Part order, while a § or position field shows that order separately from PatternID. Non-ascending PatternIDs are valid. State dependencies, Method relations, use order, and replacement relations in their own claims; do not infer them from identifiers, adjacency, Parts, or authoring work packages.

To refer to a pattern, the PatternID is enough when the surrounding text identifies the DPF. Otherwise, name the framework together with the PatternID. A citation intended to select the body published in one edition also names that framework edition.

#Select the current first result

Select the result whose condition is true now:

1. Cheap route or stop. Existing FPF or source material closes the immediate use and no later author or reviewer needs a settled edition, dependency, initial pattern-placement or relation, or publication/access boundary. Use the route or stop without E.4.PFAD or an E.9 DRR.
2. Framework-architecture answer. A choice among the five outcomes in steps 8–9 must settle a later-used boundary. Use the E.4.PFAD profile and record the selected answer, including relations among initial patterns that change the architecture, in one E.9 DRR. PFAD supplies no separate result or relation.
3. Organization-design proposal. Candidate organization claims need their own review before an architecture answer is selected. Use the C.2.1 proposal episteme locally called FrameworkOrganizationDesignProposal. The proposal is optional and is not a prerequisite for the architecture question.
4. Architecture-description use. The framework entity, architecture relation, and selected structures already exist, and the immediate question is how an architecture description may be used. Use C.30.AD; its ArchitectureDescriptionUseCard@Project name is retrieval-only. When project locality depends on a composite project U.Work, identify that Work under A.15.6, recover every precise performer's A.13 core, and use A.15.1 for independent Work admission. Add F.6 only when precise assignment-bound attribution is also current. Keep the description-use relation separate.
5. Authoring-dependency description. A named next authoring use needs a stable account of dependency availability and relevance. Use the C.2.1 episteme locally called FrameworkAuthoringDependencyDescription. It may cite the accepted answer and its E.9 DRR when that basis matters, but it is neither a prerequisite nor an automatic result of the architecture answer.

The condition, predicate, and receiving use of each result determine when it exists. The five results are alternatives rather than stages.

#Make the intended result reviewable when a separate organization proposal is needed

First make the design target present. IntendedFrameworkResultDescription is an ordinary local use name for one exact current C.2.1 U.Episteme, not a root kind or card kind. C.2.1 identifies it by:

<exact intended-result ClaimGraph,
 current DPF-authoring U.WorkPlan as EntityOfConcern,
 effective U.ReferenceScheme>

The current A.15.2 WorkPlan declares coordination claims for possible future DPF-authoring Work, the intended framework-result kind, and its acceptance target. It is present now; a dated authoring Work occurrence and the framework result may remain future. The intended-result ClaimGraph states the domain or local use frame, readers, first uses, purpose, declared relation-family coverage constraints, intended-result constraints, and acceptance conditions. The effective U.ReferenceScheme interprets those claims. One exact A.2.6 ClaimScope separately bounds which claims and uses are current; changing scope does not substitute for changing the C.2.1 identity triple.

Keep use qualification and empirical grounding in their defined neighboring relations. If interpretation for the receiving use genuinely depends on an independently selected BoundedModelUseStructure, cite that A.1.1 and A.22 structure as an optional neighboring use qualification; effective ReferenceScheme and ClaimScope retain their own positions in the account. If empirical grounding is current, state a separate C.2.1 EpistemeEmpiricalGroundingRelation to one A.1-admitted holon and the covered claim subgraph. The grounding relation, its evidence, the WorkPlan, any separately claimed dated authoring Work, any separately claimed composite project Work, and the description episteme remain distinct. Each precise performer has an A.13 core; Work claims use independent A.15.1 admission, A.15.6 when composite, and F.6 only for current precise assignment-bound attribution.

Each declared relation-family coverage constraint is one FrameworkOrganizationCandidateClaimNode with claimNodeKind=constraint. Its coveredRelationFamilyRefKindPairs[1..*] identifies each covered relation-family value together with its exact kind; admittedFrameworkUseDescriptionRef names the use for which that coverage matters; and coverageCriterionDescriptionRef states how satisfaction of this coverage constraint is judged. A current A.15.2 WorkPlan acceptance target remains a different position: cite it through designBasisRefs[] or its direct acceptance-target relation. It neither replaces the coverage criterion nor shares one union field with it.

#Create one C.2.1 proposal episteme

The organization proposal uses the present intended-result description as its one EntityOfConcern:

FrameworkOrganizationDesignProposal:
  C2_1Identity:
    entityOfConcernRef: U.EpistemeRef
      = current IntendedFrameworkResultDescription episteme
    claimGraph: U.ClaimGraph
    effectiveReferenceScheme: U.ReferenceScheme
  claimScopeRef: ClaimScopeRef defined by A.2.6
  intendedReaderDescriptionRef: U.EpistemeRef
  intendedFirstUseDescriptionRef: U.EpistemeRef
  modelUseStructureRef?: U.StructureRef
    only when one selected BoundedModelUseStructure changes interpretation for this use
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
    only for separately obtaining C.2.1 empirical-grounding relations

FrameworkOrganizationDesignProposal is a local use label for that exact C.2.1 episteme, not a second U-kind. Its one EntityOfConcern, one constituting ClaimGraph, and one effective ReferenceScheme supply episteme identity. ClaimScope, reader and use descriptions, optional model-use structure, empirical-grounding relations, A.7 provenance, F.15 proposal-status assertions when current, publication, and edition continuity are neighboring claims or relations; none is another identity slot. A changed ClaimGraph, EntityOfConcern, or effective scheme identifies another episteme. A changed grounding relation alone changes that relation, not the proposal identity.

Use F.9 for an exact cross-context local-sense translation with its own endpoints and predicate. Candidate organization claims are typed nodes in the proposal's ClaimGraph, with logical, alternative, refinement, dependency, support, conflict, and answer-to-question edges as current.

Each candidate organization claim node makes the subject-level proposal recoverable:

FrameworkOrganizationCandidateClaimNode:
  claimNodeKey: semantic key unique within claimGraph
  claimNodeKind: FrameworkOrganizationClaimNodeKindValue
  claimStatus: FrameworkOrganizationClaimStatusValue
  intendedResultAspect: FrameworkOrganizationAspectValue
  describedPositionKinds[1..*]: U.Kind
  proposedSubjectRelationSignatures[0..*]: RelationSignature
  proposedConstraintDescriptionRefs[0..*]: U.EpistemeRef
  coveredRelationFamilyRefKindPairs[0..*]: FrameworkRelationFamilyRefKindPair; cardinality [1..*] for a relation-family coverage constraint node
  admittedFrameworkUseDescriptionRef?: U.EpistemeRef; exactly one for a relation-family coverage constraint node
  coverageCriterionDescriptionRef?: U.EpistemeRef; exactly one for a relation-family coverage constraint node
  proposedInvariantDescriptionRefs[0..*]: U.EpistemeRef
  proposedDependencyDirectionDescriptionRefs[0..*]: U.EpistemeRef
  alternativeGroupKey?: semantic key unique within claimGraph
  designBasisRefs[1..*]: U.EpistemeRef
  designQuestionRefs[1..*]: U.EpistemeRef
  frameworkArchitectureSettlementConditionRef?: U.EpistemeRef

FrameworkRelationFamilyRefKindPair:
  relationFamilyRef: U.EntityRef
  relationFamilyKindRef: U.KindRef

FrameworkOrganizationCandidateClaimNode is a local ClaimGraph node form, not a U-kind and not an episteme. FrameworkOrganizationClaimNodeKindValue is the local C.2.1-compatible enumeration definition | constraint | property | assumption. A node with claimNodeKind=constraint classifies a proposed constraint claim; its proposedConstraintDescriptionRefs[] identify the exact constraint descriptions that the node asserts, while a non-constraint node may cite those refs only when they qualify that definition, property, or assumption.

A relation-family coverage constraint node also has non-empty coveredRelationFamilyRefKindPairs[], one admittedFrameworkUseDescriptionRef, and one coverageCriterionDescriptionRef; other claim nodes leave all three coverage positions absent. Each pair identifies one relation-family value and its exact kind without a union field or untyped companion list. A WorkPlan acceptance target, when current, is cited separately through designBasisRefs[] or its direct acceptance-target relation. Both constraint positions describe the proposed organization. If an obligation, recommendation-as-duty, or prohibition is current, use [A.2.8](/generated/patterns/A.2.8) -> U.Commitment with its actual duty bearer, direct predicate, modality, referents, scope, validity, and instituting basis. A system-role kind or assignment may be an applicability ground; the commitment names its actual duty bearer. If a permission, exercise, non-violation, or permission-conflict claim is current, use the exact [A.2.8.PER](/generated/patterns/A.2.8.PER) result with the participants, references, constructive ground, and qualifiers required by that selected object.

FrameworkOrganizationClaimStatusValue is the local enumeration candidateProposed | rejectedAlternative | unresolved. FrameworkOrganizationAspectValue is the local enumeration frameworkFamily | component | dependency | patternRelation | publication | access; a domain extension adds another value only together with its exact interpretation rule in the proposal's effective ReferenceScheme. Proposedness is claim modality: it says that a relation signature, position, constraint, invariant, or dependency direction is being proposed for the intended result. Actual relation occurrences and actual U.Structure values use their direct admission predicates; a pattern-use boundary condition remains a separate position.

The proposal's effective ReferenceScheme maps each organization-aspect value, described position kind, and proposed relation signature to claims about the intended result described by the EntityOfConcern; distinguishes ClaimGraph edges from the subject relations those claims propose; declares how basis and design-question refs qualify each claim; and states that claim status is modal rather than actual. Thus a claim node can propose that one pattern family depends on Core, that publication and access remain separate positions, or that one relation invariant is preserved, without pretending that the future framework or those relations already exist.

#Preserve proposal, answer, structure, and architecture boundaries

Keep the two result positions separate. If reliance-bearing E.11.PUA support materializes an exact expected-result support object for this E.4.DPF application, its expected result kind is the C.2.1 proposal episteme locally called FrameworkOrganizationDesignProposal. The intended later framework edition is described inside the separate IntendedFrameworkResultDescription and the proposal's ClaimGraph. One expectation support object never denotes both results, and neither object says the result was produced without the exact current work/result or inception claim.

Return to a framework-architecture question is separate from claim modality. When a reliance-bearing use needs an addressable return condition, E.11.PUA boundary support may name E.4.PFAD as the pattern for the next question and state which candidate claim, alternative, unresolved position, constraint, or dependency makes the downstream-used architecture boundary current. That support is adjacent to use of the proposal; it is not a proposal component and creates no PFAD result.

Subject organization is recovered from the candidate claim nodes, proposed subject relation signatures, described position kinds, constraints, invariants, dependency directions, alternatives, basis, questions, and framework-architecture settlement conditions. An A.22 U.Structure over the proposal ClaimGraph is optional and admissible only when the organization of the proposal episteme itself is a separate current EntityOfConcern. A selected BoundedModelUseStructure is a still different optional use qualification, admitted only when that exact organization changes interpretation for the receiving claim. Proposal admission depends on the proposal identity and required claim content; the optional structures describe the proposal or qualify its use. The proposal is reviewable when it contains candidate organization claims and proposed subject relation content; headings, topics, and ClaimGraph organization arrange that content.

Before realization, C.33 notes compare proposal content with a declared current comparator: design questions, present basis epistemes, candidate alternatives, a relation-family coverage constraint claim node for an admitted framework use, or an earlier existing framework edition. When coverage is the comparator, C.33 cites the exact candidate claim node and reads its covered family ref-kind pairs, admitted use, and coverage criterion. A separate WorkPlan acceptance target may appear in designBasisRefs[] or through its direct relation; the coverage criterion remains the comparator for the coverage claim. The notes may report represented, omitted, hidden, or unresolved candidate organization content relative to that basis. Comparison with actual framework structures starts after the framework entity and relevant structures exist.

Architecture-description and viewpoint use begins after the framework entity and relevant architecture relations exist. Later E.9 answers guided by E.4.PFAD, plus any C.32, C.30, and C.30.AD results, use their direct patterns and admission conditions; the proposal, intended-result description, and optional meta-structure keep their original types. C.30.AD's ArchitectureDescriptionUseCard@Project remains a retrieval cue. Actual project locality additionally requires one composite project U.Work under A.15.6 when such Work is claimed. Recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is also current, and keep its description-use relation separate.

#Describe authoring dependencies when a named next use needs them

The dependency description is optional, minimal, and status-bearing. It records current dependency positions while later authoring results retain their actual status:

FrameworkAuthoringDependencyDescription:
  C2_1Identity:
    entityOfConcernRef: U.EpistemeRef
      = current DPF-authoring U.WorkPlan
    claimGraph: U.ClaimGraph
      = dependency-position claims and their availability, relevance, value,
        subject-pattern, acquisition-condition, and next-use-boundary claims
    effectiveReferenceScheme: U.ReferenceScheme
      = interpretation of those claims for the declared next authoring use
  claimScopeRef: ClaimScopeRef defined by A.2.6
  intendedReaderDescriptionRef: U.EpistemeRef
  intendedFirstUseDescriptionRef: U.EpistemeRef
  dependencyPositions[2..*]: FrameworkAuthoringDependencyPosition
  nextAuthoringUseBoundaryDescriptionRef: U.EpistemeRef
  modelUseStructureRef?: U.StructureRef
    only when one selected BoundedModelUseStructure changes interpretation for this use
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
    only for separately obtaining C.2.1 empirical-grounding relations

FrameworkAuthoringDependencyPosition:
  dependencyPositionKey: semantic key unique within claimGraph
  dependencyKind: FrameworkAuthoringDependencyKindValue
  dependencyAvailability: FrameworkAuthoringDependencyAvailabilityValue
  dependencyUseRelevance: FrameworkAuthoringDependencyUseRelevanceValue
  dependencyValueRef?: U.EntityRef
  dependencyValueKindRef?: U.KindRef
  dependencyPatternLocator: PatternID, a non-semantic locator for the pattern whose content defines, constrains, or tests this dependency
  dependencyAcquisitionConditionDescriptionRef?: U.EpistemeRef

FrameworkAuthoringDependencyDescription is a local use label for one C.2.1 episteme, and each FrameworkAuthoringDependencyPosition is a local ClaimGraph node form. Only the enclosing description is the episteme; each position is part of its ClaimGraph. The current authoring WorkPlan, one ClaimGraph, and effective ReferenceScheme supply the description's identity. ClaimScope, reader and use descriptions, optional model-use structure, empirical grounding, provenance, assessment status, publication, and edition continuity remain separate. dependencyPatternLocator is an ordinary non-semantic PatternID that identifies the pattern whose content defines, constrains, or tests the dependency. A dependency that is also a MethodDescription identifies its episteme and the admitted Method it describes separately and applies the full A.3.2 test.

FrameworkAuthoringDependencyKindValue is fpfCoreEdition | sourceBasis | frameworkArchitectureAnswer | nameRoute | patternDraftSet | relationAndEditionRecords | publicationOrAccess | packageQuality | improvement | currentness. FrameworkAuthoringDependencyAvailabilityValue is available | missing. FrameworkAuthoringDependencyUseRelevanceValue is currentForNextAuthoringUse | retainedForLaterUse | relevanceUnsettled.

The minimum positions are one fpfCoreEdition and one sourceBasis. Add another dependency kind only when the declared next authoring use relies on it or deliberately retains it for a named later use. A frameworkArchitectureAnswer position is optional: include it only when that use needs the accepted answer or its rationale, and point to the accepted answer and [E.9](/generated/patterns/E.9) DRR rather than to a PFAD relation or record.

When dependencyAvailability=available, the exact dependency value and kind refs are present and the acquisition-condition description is absent. When dependencyAvailability=missing, those refs are absent and the acquisition-condition description is present. Relevance remains independent: missing + currentForNextAuthoringUse blocks the next use and opens the stated return, while missing + retainedForLaterUse does not block current work. Record a condition on using an available dependency in the pattern that defines the dependency or in the next-use boundary, not in the acquisition position.

As authoring proceeds, the same description may refer to an accepted framework-architecture answer and its [E.9](/generated/patterns/E.9) DRR; [E.4.PFR](/generated/patterns/E.4.PFR) relation records and edition dependencies; [G.2](/generated/patterns/G.2) source packs; subject-home NameCards; [E.8](/generated/patterns/E.8) pattern drafts; [E.24.PUB](/generated/patterns/E.24.PUB), [E.11](/generated/patterns/E.11), or [E.17](/generated/patterns/E.17) publication and access uses; [E.4.DPF.DA](/generated/patterns/E.4.DPF.DA) evaluation results; [E.23](/generated/patterns/E.23) improvement results; and [G.11](/generated/patterns/G.11) currentness relations. Identify each dependency value, relation occurrence, evaluation result, edition relation, and receiving use separately, and apply the pattern that defines or constrains that object or use. The framework edition, package architecture, publication occurrence, publication form, carrier, dated authoring Work, and each dependency value retain their direct identities.

#Archetypal Grounding

Tell: A hydroponic-cucumber framework begins with crop-production concerns, horticulture and greenhouse-control sources, local examples, and FPF Core dependency. Its first all-in-one publication carrier is for domain users, while relation records, source packs, and quality evaluations remain separately recoverable.

Show: A neural-network architecture framework may draw on dataflow architecture, model components, training and inference concerns, evaluation practice, and recent architecture-analysis work. The framework can describe layers, blocks, flows, optimization constraints, and interpretability concerns. For each resulting pattern, choose the smallest source route that preserves the relied claims and limits; use G.2 only when the framework needs a broad, refreshable SoTA pack and downstream Part G handoffs. Draft the pattern with E.8, and record material relations with E.4.PFR when a named use needs them.

Show: A workspace-specific Codex process framework can contain prelanding and baton-handoff patterns. It should state its local context, dependency on FPF Core, process sources, local carriers, and refresh route. A useful local checklist stays a local checklist until it has source grounding, pattern bodies, direct assertions of material relations, and quality evaluation. Add a relation or edition record only when a named maintenance use needs it.

Show: An enterprise local practice framework for architecture review starts from the organization's review setting, internal policies, proprietary examples, and approval path. It can depend on FPF Core and on a domain principle framework, but its confidential evidence, any local records about exact system-role classifications or assignment occurrences, training plan, and rollout telemetry stay local. Access, custody, maintenance, responsibility, authority, and approval remain separate direct claims.

Enterprise local-practice slice:

Replayable authoring slice:

#Pattern-address and reorder slice

A Systems Engineering DPF edition gives SYSE.22 a stable address and places it after SYSE.2 because that order helps its readers. A later edition may move SYSE.22 without renaming it when its recurring problem and working answer continue; the ToC and body order change together, while old citations still resolve through the same PatternID. If a later repair splits that working answer, only the continuing answer keeps SYSE.22; the other answer receives a new unused PatternID, and readers of the old reference get a short migration assertion or an explicit stop.

#Local-mantra authoring slice

After the HC.NutrientMonitoring Solution is stable, its authors use the local mantra: Name the crop stage and root-zone condition; establish that the measurement is usable in its current calibration range; compare it with the stage-specific range; change the control setting only within the declared operating boundary; return when crop stage, sensor validity, or operating boundary changes. The formula helps a grower or crop-system architect keep the pattern's operative distinctions and return condition in attention. It remains Plain wording inside HC.NutrientMonitoring; it is not another nutrient-control method, work order, U-kind, or F.17 publication obligation.

If a seminar instead needs to show alternative continuations for invalid measurement, out-of-range nutrient condition, control saturation, and crop-stage transition through one named wider unfolding structure, the authors open A.22.CGUS and build a demonstrative walkthrough. They do not obtain that structure merely by extending or repeating the local mantra.

#Optional organization-proposal slice

A team intends a new clinical-method DPF, and a named review use needs candidate organization claims before an architecture answer is selected. It creates one current U.WorkPlan for possible future DPF-authoring Work, then one C.2.1 IntendedFrameworkResultDescription whose identity is its exact intended-result ClaimGraph, that WorkPlan as EntityOfConcern, and its effective ReferenceScheme; ClaimScope remains separate. FrameworkOrganizationDesignProposal uses that description as its EntityOfConcern and proposes candidate pattern-family, dependency, publication, and access relations in one ClaimGraph. The proposal is the current result. No future framework entity, actual architecture, architecture description, dated Work, or production relation is asserted.

#Coverage and acceptance slice

The proposal's medication-review coverage criterion names the pattern families whose representation is necessary for that declared use. One constraint claim node names the covered relation-family refs with exact kinds, that admitted use, and the coverage criterion. The authoring WorkPlan separately cites an acceptance target for review completion. C.33 uses the coverage node as comparator when evaluating proposal coverage; the WorkPlan target does not replace the criterion.

#Empirical-grounding and use-frame stress slice

The intended-result description has a separately obtaining EpistemeEmpiricalGroundingRelation to MedicationReviewTeam@Hospital-A, an A.1-admitted holon, covering the exact supported claim subgraph. The holon is not an episteme identity slot. A request to rely instead on a consortium first rechecks the empirical-grounding relation and evidence, effective ReferenceScheme, ClaimScope, and any independently selected BoundedModelUseStructure. Changing only the empirical ground changes that relation; changing the ClaimGraph, EntityOfConcern, or effective scheme identifies another episteme. F.9 opens only if an exact cross-context local-sense translation is actually current, not merely because the maintaining organization changed.

#Optional authoring-dependency slice

A named next authoring use needs a stable dependency account. The Core edition is available and relevant now, so its dependency position has exact value and kind refs and no acquisition condition. The accepted architecture answer is cited through its E.9 DRR because this use needs that rationale; it is not a mandatory PFAD dependency position. A publication carrier is missing but retained for later use, so its position has no value refs, has an acquisition-condition description, and does not block current pattern drafting. A missing source pack marked currentForNextAuthoringUse blocks the next use and opens the stated return. Availability never stands for relevance.

#Framework-evolution slice

A new controlled-environment study changes the admissible nutrient range used only by HC.NutrientMonitoring. Because this example selected a broad, refreshable G.2 pack, first revise that pack and preserve the displaced source reading. Use E.4.PFR to identify the nutrient pattern, its source-reuse relation, and its dependent examples as the affected set; use E.21 to evaluate the revised pattern body; use E.23 for repeated improvement of that pattern edition; and use G.11 for currentness, telemetry, and deprecation or supersession of exposed editions. Unaffected climate-control and harvest-feedback patterns remain current. E.4.PFAD stays closed while framework family, pattern split, relation structure, publication-form, presentation-carrier or access-route architecture, and dependency boundary remain unchanged; a change to one of those decisions makes PFAD current again.

#Bias-Annotation

Scope: Use this pattern to select, author, assemble, and refresh FPF-grounded DPF or LPF editions and their first-use publication forms, presentation carriers, and access routes. Lifecycle, product-ontology, research-method, and general publication questions return to their owning patterns.

The first recurring drift is source-summary confidence: a summary feels sufficient because it names the right domain terms. Choose the smallest route that keeps the relied claims, rejected readings, limits, and source editions recoverable, then carry them into pattern Solutions and examples. Use a G.2 pack only when the question needs its broad, refreshable source frame and downstream handoffs.

The second recurring drift is publication-carrier-first authoring. Publish after the architecture decision, direct assertions of material relations, and source-return notes are recoverable, together with any relation or edition records required by a current maintenance use.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Using the exact authoring Method and MethodDescription while keeping dated Work, results, receiving uses, editions, relations, package architecture, and publication objects explicit adds overhead before a local framework becomes durable. In return, the source basis, Core change impact, relation semantics, production and membership claims, and currentness debt become reviewable at their own boundaries.

The pattern also makes local publication more useful. Readers get a coherent publication or practical-use carrier, while maintainers can still inspect the framework edition, source pack, relation records, decision records, and quality route.

#Rationale

Domain and local frameworks are FPF-grounded framework editions for declared domain or local use frames. They need domain source work, FPF authoring discipline, architecture decisions, direct relation assertions, quality loops, and refresh routes. Add the relation or edition records needed for a current maintenance use; a direct assertion closes the task when no such representation is needed.

Its contribution is one framework-authoring Method plus Plain selection and branching guidance. This episteme qualifies as its A.3.2 U.MethodDescription because it describes that admitted Method as its EntityOfConcern. E.8 supplies the pattern-authoring and publication-form discipline; A.3.2 supplies MethodDescription qualification. When an A.22.CGUS is genuinely current, admit it separately with exact conditions, continuations, stops, and demonstration. Every produced or selected result still needs a receiving use and the pattern that defines, constrains, or tests that result or use relation.

#SoTA-Echoing

These comparisons apply the canonical E.8:11 contract to the authoring and assembly questions governed here. They do not create a second SoTA definition or a shelf of current sources.

Source identity and currentness support replay and targeted refresh only. A later publication date, maintained repository, institutional status, or wider adoption cannot raise these comparisons; G.11 reopens only the smallest receiving rule when changed evidence can alter the selected answer.

#Relations

• Uses: direct source reliance when one source closes the question; F.0.1 for source-local meaning; F.1 for a relevance-based source cut; F.0.2 for one bounded conceptual-synthesis result; and G.2 only for the broad, refreshable CG-Frame pack. Identified pack claims and provenance may enter F.0.2, but the pack does not establish its result.
• Uses: A.3.1 for the framework-authoring Method and A.3.2 for this independently qualified MethodDescription; A.13 for every precise performer's core and same obtaining assignment; A.15.1 for independently admitted dated authoring Work; F.6 only for a current precise assignment-bound attribution; A.15.PROD for any local inception or production-completion claim; A.6.1 for an actual application and its bindings; E.8, E.10, and F.18 for pattern drafting, wording discipline, and names; and E.10.ARCH for local domain wording restoration when a recurring problem has been shown.
• Coordinates with: E.4 for family membership and the proportional support-unit/adjacent-product boundary, and E.4.PFAD for architecture decisions; uses C.32.MWA when several practice structures need one synthesis and E.23.CDI only when capability development for a named Work family is current.
• Coordinates with: C.2.1 and A.2.6 for framework/result episteme identity, effective ReferenceScheme, empirical-grounding relations, and ClaimScope; A.1.1/A.22 only for an independently selected model-use structure; A.22.CGUS only for a genuinely admitted conditional unfolding; E.4.PFR for separately identified relation records and for dependency, edition, compatibility, deprecation, and supersession effects; C.30.AD for post-existence architecture-description use and its retrieval-only project card name; and E.24.PUB for publication occurrence, form, and carrier.
• Coordinates with: C.33, C.34, and C.35 for carrier preservation and admission.
• Coordinates with: E.22 for quality-evaluation framing when needed, E.4.DPF.DA for DPF package adequacy, E.21 for pattern-quality evaluation, E.23 for repeated improvement, E.19 for admission or profile gating when claimed, and G.11 for currentness.
• Use next when current: E.11.PFP for the common framework publication form, E.11 for practical-use discoverability, E.11.DSG for a separate DPF Suite Reference when one working question may need results from several DPF product series, and E.17 for publication discoverability rather than framework authoring.

#E.4.DPF:End

#Domain Principle Framework Package-Adequacy Evaluation CharacteristicSpace

Type: Evaluation (E) Status: Stable Normativity: Normative unless marked informative.

#Problem frame

Use this pattern when a framework author, reviewer, steward, or AI agent must decide whether one Domain Principle Framework or Local Practice Framework package is good enough for one declared domain or local use.

Primary EntityOfConcern: one exact authored framework episteme edition checked for one declared package use. Name the visible publication form, presentation carrier, access-facing presentation carrier, or access route being inspected without turning it into the framework edition or package architecture. The first useful result is one aggregate C.2.1 result episteme with all D1–D12 claims, its local status, and the smallest repair or explicit no-proposal disposition. The Solution gives the additional assurance detail only when a receiving use relies on it.

Use E.4.DPF.DA, rather than E.2.DA, for ordinary DPF package evaluation. E.2.DA asks whether FPF-level objects realize the FPF Pillars for broad FPF use; a DPF package must serve one declared domain or local use frame while depending on FPF Core without redefining it. Recover that frame through effective ReferenceScheme, ClaimScope, reader, intended use, qualification window, and only when interpretation depends on it an independently selected BoundedModelUseStructure. Add a non-use boundary only for a named competing use or plausible observed confusion. Use E.2.DA when the package changes or claims FPF-level Pillar adequacy.

Use E.21 for the quality of individual DPF pattern bodies. Use this pattern for the package as a whole: domain scope, source basis, Core dependency, the framework publication form borne by its selected carrier, pattern-set coverage, relation and edition records, local publication, evaluation route, refresh route, and adoption utility.

#Problem

DPF packages will often be produced quickly from source material, prompts, external literature, local practice, or generated candidates. Some are good enough as seeds; some can answer a domain question for an AI agent; some are public-ready publication carriers; some are only source summaries wearing pattern headings.

Without a DPF-specific adequacy evaluation, teams tend to use one of three wrong substitutes:

• they apply E.2.DA and ask whether the package is "FPF-like in general", even though the package is meant for one domain;
• they average E.21 scores of individual patterns and miss package-level failures such as missing source packs, broken dependency direction, poor first entry, or stale edition records;
• they inspect section presence and conclude that an all-in-one carrier, map, or seed package is adequate because it has patterns, a table of contents, a readme, a preface, maps, and sources.

The result is adoption risk. A reader may get a fluent local framework that does not state its domain boundary, does not preserve rival source traditions, duplicates FPF Core ontology, hides relation functions, has no refresh route, or cannot tell a practitioner what typical problem is live, which known failure mode to avoid, and which SoTA solution move to try first.

#Forces

#Solution

Start here with one ordinary assessment route:

1. Pin the exact authored framework episteme edition and declared package use, then name the effective ReferenceScheme, ClaimScope, working reader, intended use, qualification window, evidence basis, floor, and any independently grounded non-use boundary that changes the result.
2. Run PFM1, PFM1a, and PFM2–PFM12 where applicable and give each one a pass, fail, or not-applicable-with-reason disposition.
3. Judge every D1–D12 coordinate with one ordinal value, short rationale, exact evidence locus, and smallest repair or explicit no-proposal disposition.
4. Constitute one aggregate C.2.1 result episteme carrying those coordinate claims, protected trade-offs, the local DPFPackageAdequacyStatus, and the first repair or no-proposal disposition.
5. State the next usable action, stop or repair, and reopen condition, then name any separate receiving use such as E.19 admission or refresh, assurance, publication, F.10 status use, or E.23 repair. Add a non-use statement only when a plausible reader has an independently grounded reason to confuse those uses.

The first useful result is that aggregate episteme and its local status for the declared use. Stop with seedOnly or repairBeforeDPFUse when the package or evidence does not support the declared floor; the route still produces a useful bounded result and next repair.

For a new or substantially revised DPF, add four focused questions:

• For this exact current framework edition, do the selected pattern sets and relied-on external results actually work together in one first use and one representative case across problem families well enough to make good on the public field promise? Record the answer as D12DomainProblemFamilyCoverageAdequacy; a pattern count or evidence that an earlier review occurred is not evidence.
• Where the sources describe practice architecture, does the package preserve both genuine first-then flow and genuine simultaneous bounded contribution? Use a completed C.32.MWA result as evidence when several structures need reconciliation; do not repeat that Method's actions here. Use an E.23.CDI result only when capability development changes the package claim.
• For the named first use, are all required patterns from this DPF present? For every relied-on external result, are its exact identity, direct kind, supplying product and edition or current state, receiving use, discovery route, material currentness or availability, and externality explicit? For each important source-backed claim, can a reviewer find the source and tell whether the evidence supports, suggests, or only motivates it?
• When the declared use includes a public presentation carrier, does that carrier bear the framework publication form defined by E.11.PFP while keeping its DPF-specific body and references under E.4.DPF? Keep PFM1 responsible for practitioner entry and navigation; use PFM12 only for the remaining common-form and edition-projection questions. Form conformance does not prove field coverage or package adequacy.

These questions test the package and its evidence. They do not prescribe another Method to perform or turn use of a Method result into an edition dependency.

Assurance and object boundary after the ordinary route. Evaluate one exact authored framework episteme edition for one declared package use through a DPF-specific adequacy characteristic space. The evaluation is derived from the shape of E.2.DA, but it is not the FPF Pillar evaluation. It asks whether the selected framework edition, together with its separate package architecture, pattern set, source basis, architecture decisions, relation records, edition dependencies, publication and access uses, quality evidence, and refresh route, realizes FPF-grounded domain value for one declared use frame.

Keep the evaluation objects separate:

1. the exact authored framework episteme edition of concern, identified under C.2.1;
2. its package architecture, E.4.PFAD architecture decisions, E.4.PFR relation records and edition dependencies, selected pattern set, source-use results, publication units and occurrences, publication forms, presentation carriers, access-facing presentation carriers, access routes, and actual access or use relations;
3. the effective U.ReferenceScheme, A.2.6 ClaimScope, working reader, intended use, qualification window, any independently grounded non-use boundary, and an optional independently selected BoundedModelUseStructure only when its organization changes interpretation;
4. this E.4.DPF.DA characteristic space and evaluation specification;
5. one exact semantic package-adequacy-evaluation U.Method;
6. an ordinary evaluator action left outside Work admission; or, when dated assessment U.Work is asserted, references to the exact actual evaluator System recovered through A.13 and one independently valid A.15.1 Work account; only when the result expressly represents precise assignment-bound attribution, references to the same obtaining A.13 assignment and applicable F.6 relation occurrences; and, independently, an A.6.1 application only when the assessment uses one exact operation declared by a separately admitted Mechanism and the receiving claim depends on its bindings;
7. twelve ordinal coordinate-result claims about the same exact framework edition;
8. one aggregate C.2.1 result episteme carrying those claims, the local package-adequacy status, protected trade-offs, first repair or no-proposal disposition, reopen condition, and any grounded non-use boundary;
9. witnesses and A.10 evidence-use relations, plus an optional evaluation record that packages references without performing the assessment or granting authority; and
10. any F.10 status use, E.19 admission or refresh decision, assurance, publication, later improvement Work, and changed framework edition.

Use this compact input/action/result separation:

DPFPackageAdequacyEvaluationConfiguration:
  FrameworkEpistemeEditionOfConcernRef: <one exact authored U.Episteme>
  DeclaredVisiblePackageFormOrUse: <plain description of the exact visible form or use being evaluated; not a U-kind>
  PackageArchitectureRefs:
  FPFCoreEditionRef:
  DependencyAndEditionRefs:
  SourceBasisRefs:
  PFADDecisionRefs:
  PatternSetRefs:
  RelationRecordRefs:
  SelectedPublicationUnitRefs:
  PublicationOccurrenceRefs:
  PublicationFormRefs:
  PresentationCarrierRefs: <exact U.PresentationCarrier refs that bear the selected publication forms>
  AccessFacingPresentationCarrierRefs: <exact U.PresentationCarrier refs that bear access-facing forms>
  AccessRouteRefs: <services, endpoints, retrieval or search routes, or assistant integrations>
  ActualAccessOrUseRelationRefs:
  QualityEvidenceRefs:
  RefreshRefs:
  EffectiveReferenceScheme:
  ClaimScope:
  WorkingReaderOrOperatorScope:
  IntendedUse:
  NonUseBoundary?: <only for a named competing use or plausible observed confusion that changes this result>
  QualificationWindow:
  ModelUseStructureRef?: <only when one selected BoundedModelUseStructure changes interpretation>
  DPFPackageAdequacyCharacteristicSpaceRef: <exact A.19 characteristic space>
  DPFPackageAdequacyEvaluationSpecificationRef: <this E.4.DPF.DA edition>
  SemanticDPFPackageAdequacyEvaluationMethodRef: <exact U.Method>
  EvaluationEvidenceBasis:
  DeclaredFloor:
  EvaluationConfigurationRef:
  OrdinaryEvaluatorActionDescription?: <for a judgement or action left outside Work admission>
  MechanismOperationApplicationRef?: <one exact A.6.1 application only when the assessment
    actually uses an operation declared by a separately admitted U.Mechanism and the receiving
    claim depends on its actual input and result bindings>
  AssessmentWorkAdmission?: <omit for an ordinary judgement or action not admitted as U.Work;
    when present, cite the exact A.13 actual-performer basis and independently valid A.15.1 Work account rather than redeclaring them; add assignment-bound attribution references only when this result expressly represents that attribution>
    AssessmentWorkAccountRef: <one independently valid A.15.1 Work account>
    AssessmentWorkRef: <the dated U.Work used by this result>
    EvaluatorSystemRef: <the exact actual evaluator U.System already recovered through A.13>
    PerformedUnderAssignmentRefs?: <the applicable obtaining F.6 relation occurrences through the same A.13 assignment, only when this result expressly represents precise assignment-bound attribution; omit otherwise; missing or failed F.6 leaves the Work account intact>
DPFPackageAdequacyResultEpisteme:
  EntityOfConcern: <same exact FrameworkEpistemeEditionOfConcernRef>
  EffectiveReferenceScheme:
  ClaimGraph:
    ClaimScope:
    WorkingReaderOrOperatorScope:
    IntendedUse:
    NonUseBoundary?: <same conditional boundary when present>
    QualificationWindow:
    CoordinateResultClaims: <all D1..D12 values, rationales, evidence loci, repairs/no-proposals>
    ProtectedTradeoffSet:
    DPFPackageAdequacyStatus: <local result value>
    FirstRepairOrNoProposalDisposition:
    ReopenCondition:
  AssessmentAccountRef:
  ResultWitnessRefs:
  ResultEvidenceUseRefs:
DPFPackageAdequacyEvaluationRecord: <optional packaging of configuration, assessment account,
  result, witnesses/evidence use, reopen refs, and any grounded non-use boundary>

These names are local record and claim shapes, not new U-kinds. DeclaredVisiblePackageFormOrUse is open plain wording for the exact form or use being checked; it neither types nor identifies the framework or package. The separately typed reference fields keep publication units, forms, U.PresentationCarrier values, access routes, and actual access or use relations distinct. If the visible material has no independently admitted single package entity, do not make a file set or list into one: keep the exact framework episteme edition as EntityOfConcern and cite its package architecture, records, contents, publication and access relations, forms, carriers, and routes separately in the configuration and evidence basis. A file boundary, manifest, directory, table order, publication, carrier, callable service, or endpoint establishes neither package architecture nor membership.

The characteristic table and this specification describe how to evaluate; the semantic Method, evaluator action, dated Work, A.6.1 application, and result keep their own identities. A practitioner may make an ordinary package-adequacy judgement without classifying it as U.Work or asserting an A.6.1 application. Such an application exists here only when one exact operation declared by a separately admitted Mechanism is actually used and the receiving claim depends on its bindings; Work admission neither creates nor requires it. If the account instead claims dated assessment Work, recover the exact actual evaluator System through A.13 and cite one independently valid A.15.1 Work account. Only when the result expressly represents precise assignment-bound attribution does it also cite the same obtaining A.13 assignment and applicable F.6 relation occurrences. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. The evaluator System acts. A local evaluator system-role classification is an optional neighboring claim. The local account exposes assignment or F.6 references only for that attribution branch. Constitute the coordinate claims and aggregate result under §4.3, and establish each later receiving use through its own relation under §4.5.

Each coordinate value is an ordinal content-evaluation quality ascription about the same exact framework episteme edition under the declared ReferenceScheme, ClaimScope, use, and qualification window. It is not a U.Measure, measurement output, average, vote, maturity stage, or status use. The aggregate result episteme has its own C.2.1 identity; empirical grounding, witness presence, evidence use, publication, and evaluator identity remain neighboring relations or objects rather than identity slots.

#Ordinal scale

Default floor is 4 for public, teaching, enterprise, operational, or reliance-bearing DPF use. A fast seed or exploratory prompt output may use floor 3 only when its limits, missing evidence, next repair, and reopen condition are explicit.

#Required coordinates

Every E.4.DPF.DA result includes every coordinate below, including a result for a seed: assign the value that the seed earns. A bounded diagnostic may borrow selected questions while stating its limited scope; it does not claim an E.4.DPF.DA result or local status.

In this pattern, known failure modes means beginner mistakes and experienced-practitioner failures caused by stale, local-only, or non-SoTA practice. Do not narrow the check to novice errors only.

#Result row shape

The aggregate E.4.DPF.DA result episteme carries twelve coordinate-result claims and may present them with this table shape:

For values 1..4, explain why the lower adjacent value would understate the evidence and the higher adjacent value would overstate it. For 0, explain why 1 would overstate the evidence and what would raise the value or reopen it. For 5, explain why 4 would understate the evidence and what would lower the value or reopen it.

Each row is one ordinal content-evaluation quality ascription about the same exact framework episteme edition and keeps recoverable the effective ReferenceScheme, characteristic, scale value, evaluation rule or probe, ClaimScope/use/window, assessment account and any asserted Mechanism-operation application, short rationale, evidence locus, and repair or no-proposal. A prose verdict, checklist-count result, table without evidence loci, average of E.21 pattern values, favorable status label, or table detached from an aggregate C.2.1 result episteme is only assessment material. None is a U.Measure, measurement output, performed assessment, admission, or authority.

#DPF-wide package-form checks

Run this subpass when the declared use depends on an all-in-one DPF publication carrier, selected-host set, card set, skill-pack or index carrier, returned response artifact, MCP or other service route, retrieval or search route, assistant integration, or another reader-facing form. Inspect the exact publication form and U.PresentationCarrier that bear it, and inspect any service or route separately; do not substitute editable sources, a manifest, or a successful build run. These checks do not replace the twelve coordinates; they supply package-level evidence mainly for D1, D2, D4, D5, D7, D8, D9, D10, D11, and D12.

When the declared package use includes accepted-source integration or continuity with a predecessor publication, use a current E.4.PFIP conclusion as evidence for the affected coordinates. Keep the PFIP conclusion and the package-adequacy result separate: the first reports publication integration or continuity, and the second judges package adequacy for the declared use.

PFM1 owns practitioner entry, navigation, and the order in which readers meet the ToC, Readme, and Preface. PFM1a owns the product-native key/form declaration, the explicit examples-not-coverage boundary, and the content judgement that a mantra materially improves each selected cross-pattern card while a plausible direct example remains sufficient without one. PFM12 owns only the remaining common-form and edition-projection agreement. If one observation bears on PFM1, PFM7, or PFM12, record it once, point every affected disposition to the same evidence and repair, and lower an affected coordinate only once for that defect. Give the checks different dispositions only when they discriminate different defects with different repair actions.

A failure in this subpass lowers the affected coordinate even when individual pattern bodies pass E.21. Repair the package carrier, relation record, first-entry route, dependency record, or support-map placement; do not copy the package-form proof into pattern bodies.

#Evidence basis and where to check it

Use these sources and patterns instead of expanding this pattern into a package bureaucracy:

When a coordinate is below floor, return a finding or repair proposal. When a coordinate is at 4 and improvement is requested, search for a substantive non-dominated improvement. Do not raise a value by adding proof apparatus, more maps, more citations, or quality-status prose unless the package becomes easier to use, more source-grounded, more accurately bounded, or more refreshable.

#Local result status and receiving-use boundary

DPFPackageAdequacyStatus is a local admissible-use claim carried by the aggregate result episteme. It reports the package-adequacy evaluation result for the declared scope. A receiving process may use it for an F.10 status use, E.19 admission or refresh decision, assurance, publication, work authorization, or improvement Work only through that use's own exact relation and decision rule.

#Archetypal Grounding

Tell: A personal-development DPF is generated in one short run. It may have useful principles and pattern seeds. The evaluator can make an ordinary package-adequacy judgement without asserting U.Work. If a dated evaluation is instead admitted as Work, recover the exact actual evaluator System through A.13 and cite one independently valid A.15.1 Work account. Add the same obtaining A.13 assignment and applicable F.6 relation occurrences only when this result expressly represents precise assignment-bound attribution; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Separately cite an A.6.1 application only if the evaluation actually uses one exact operation declared by a separately admitted Mechanism and the result depends on its bindings; Work admission does not supply that application. The aggregate C.2.1 result can then state local status seedOnly, with high coordinate claims for first-entry utility and low claims for source currentness, heterogeneous probes, relation records, or refresh. The prompt output, evaluator action, any Work, any attribution, any Mechanism-operation application, result episteme, and local status remain distinct. That status is not failure or admission; it is an honest package-use result and next repair route.

Show: A domain DPF all-in-one publication carrier contains domain patterns, a source-use map, a Core-bridge map, relation records, and heterogeneous acceptance cases for several user situations. E.4.DPF.DA asks whether those cases actually force the pattern set to solve different domain problems, whether source rows changed pattern obligations, whether maps are reachable during work, and whether the package's local evaluation pattern can feed E.22 and E.23 without becoming a hidden Core dependency.

Show: A proposed systems-management DPF promises help with service launch, cross-team coordination, incident response, and feedback-based improvement. D12 checks whether the selected pattern sets and their actual relations serve all four problem families, whether one service-launch case needs patterns from more than one set, what remains omitted, and where later authors return to the sources. One source describes a genuine first-then incident flow; another describes monitoring, coordination, and resource provision contributing at the same time. The evaluation preserves both readings. A completed C.32.MWA result may supply that evidence, but the evaluator neither repeats the Method's actions nor treats use of its result as an edition dependency. The named first use must include every required pattern from this DPF. For each relied-on external result, the assessment names its actual kind and supplying product, the receiving use and discovery route, material currentness or availability, and the fact that it remains external. PFM11 then checks whether the carrier tells readers what it exposes and omits. PFM1 checks practitioner entry and navigation; PFM12 checks only the remaining common-form and edition-projection agreement. A shared observation and repair are recorded once. None of these form checks substitutes for D12.

Show: A hydroponic-cucumber DPF has excellent crop-control sources but no relation records and no first-entry carrier. E.21 may find that individual crop patterns are good, but D5PackageFormLayeringAndRelationAdequacy and D2DidacticEntryAndAdoptionAdequacy stay below floor until relation records and first-use routes exist.

Near miss: A DPF all-in-one publication carrier has a huge map before the pattern bodies. The map is correct but cold readers do not know when to open it. D2 and D5 fall unless pattern relations, low-value repair actions, or first-entry text route readers into the map from a real work trigger.

Near miss: A DPF has polished readme and Preface prose, but neither says what selected domain structure the publication/access expression exposes, what it deliberately coarsens or abstracts, or where a reader returns for fuller source and pattern detail. If the carrier is based on an architecture description, view, model, or graph, it also hides the fact that the intermediate source already selected and coarsened structure on the route source structures -> architecture -> architecture description or view -> publication/access expression. D1, D2, D5, D7, D8, and D11 fall because the carrier may be pleasant but its structure-capture claim is not inspectable.

#Bias-Annotation

Scope: Limited to evaluating one exact FPF-grounded DPF or LPF edition for one declared package use. It is not a whole-FPF evaluation, a universal product score, an admission decision, or a publication template.

The first recurring drift is whole-FPF overreach: a DPF package is judged as if it had to cover every domain. Declare one domain or local setting and evaluate adequacy for that setting.

The second recurring drift is local excellence laundering: good-looking patterns, a polished monolith, or generated fluency hides missing source, relation, edition, and refresh structures. Evaluate the package coordinates, not only pattern bodies.

The third recurring drift is quality-proof leakage: evaluation results, review status, or package-architecture evidence are copied into user-facing pattern prose. Move that evidence to this evaluation, E.21, E.19, E.11, I.2, or the applicable publication-evidence locus, and keep only the user-facing move or boundary in pattern bodies.

The fourth recurring drift is invisible carrier narration: the package is presented as a transparent list of principles, so nobody asks which domain structures were selected, coarsened, abstracted, omitted, or already transformed through source structures -> architecture -> architecture description or view -> publication/access expression before the publication carrier was written. Make the Readme, Preface, or access front provide a short carrier structure-account and check it through PFM11.

The fifth recurring drift is assurance by duplication: the evaluation copies the action sequence of C.32.MWA or E.23.CDI and treats completion as package proof. Use the completed result only where it bears on a named coordinate, then run the package's own probes.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The pattern adds one package-level evaluation on top of individual pattern checks. The cost is worthwhile when DPF packages become reusable across domains, enterprises, AI-agent prompt packs, teaching materials, or local practice frameworks.

It also prevents a common false choice. A DPF seed can be useful without pretending to be public-ready, and a public-ready package can remain domain-bounded without pretending to be FPF Core. D12 adds one field-coverage judgement and PFM12 one incremental publication-form check. Neither starts a second evaluation pass, copies another Method's steps, or charges a PFM1 observation twice.

#Rationale

FPF needed E.2.DA because a local edit can improve one pattern while harming the whole language. DPF packages need the analogous but narrower instrument: a package can have good patterns while failing as a domain framework. Domain source grounding, relation architecture, first-entry adoption, package publication, and refresh are package-level effects.

The coordinate set mirrors the spirit of the FPF Pillars but changes the adequacy question. FPF asks whether the whole framework remains broadly first-principle and cross-domain. A DPF asks whether one bounded domain or local framework is strong enough for its declared use while preserving dependency on FPF Core and a route back to its domain sources. D12 makes that field-scale question explicit; the two-way architecture probe prevents a source diagram or chapter order from supplying the answer by appearance.

#SoTA-Echoing

The comparisons below apply the single canonical SoTA contract in E.8:11 to package evaluation. Source status, date, and prevalence remain replay information and cannot raise an adequacy result.

Currentness checks remain separate from adequacy values. G.11 reopens only the affected comparison, coordinate, case, or boundary when changed evidence can alter the answer; a new edition, current catalogue entry, maintained tool, or recent paper alone changes no value.

#Relations

• Builds on: A.19.ECS for evaluation characteristic-space construction.
• Specializes by object: E.2.DA supplies the adjacent form for complete multi-coordinate adequacy evaluation, but this pattern changes the evaluated object from FPF-level object to DPF package edition.
• Coordinates with: E.4 for framework family; the exact E.4.DPF authoring U.Method and MethodDescription; E.4.PFAD for architecture decisions; E.4.PFR for relation records and edition dependencies; and the separate package architecture. Their coordination list and document order identify neither the authoring Method nor the evaluation Method.
• Coordinates with: C.2.1 for framework and result episteme identity and the effective ReferenceScheme; A.2.6 for ClaimScope; A.1.1 and A.22 only for an interpretation-changing selected model-use structure; A.3.1 and A.3.2 for the semantic evaluation Method and its description; A.13 for the exact actual evaluator and A.15.1 for one independently valid Work account when dated assessment Work is asserted; A.2.1 and F.6 only when the result expressly represents precise assignment-bound attribution through that same obtaining A.13 assignment; A.6.1 only for an actual application of an operation declared by a separately admitted Mechanism and its bindings; A.10 for evidence use; and G.2 and G.11 for source packs, source currentness, and refresh.
• Coordinates with: E.21, E.19, E.22, and E.23 for individual pattern quality, admission review, evaluation framing, and repeated improvement.
• Uses: F.19 for precise plain-language checks and ordinary wording repair; E.10 for cues and unresolved meaning routes.
• Coordinates with: E.24.PUB for publication occurrence, form, and presentation carrier; E.11.PFP for the common framework publication form; E.4.PFIP only for a separate accepted-source integration or predecessor-continuity conclusion; and E.11, E.17, F.18, C.33, C.34, and C.35 for first entry, publication or access use, naming, preservation, correspondence, and produced-carrier admission.
• Coordinates with: B.1.5, A.22, A.22.CGUS, and C.30.AD for the two-way architecture probe; use a completed C.32.MWA result when several practice structures need reconciliation and an E.23.CDI result only when capability development changes a named coordinate.
• Coordinates with: E.2.DA only when a DPF package change claims FPF-level Pillar adequacy or proposes Core amendment effects.

#E.4.DPF.DA:End

#Pattern-Framework Relation and Edition Discipline

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative.

Use this when. Use E.4.PFR when a named framework-maintenance, edition-impact, comparison, publication/dependency-repair, or refresh task needs a stable relation-specific row across patterns, framework editions, publication or access carriers, source packs, decisions, generated carriers, or quality results.

First useful move. State the exact subject assertion in ordinary C.2.1 form: name the subject or claim, exact relation function, exact defining or constraining ClaimGraph, polarity, and the current fact or condition. Stop there unless an identified maintainer or tool consumes standardized relation form.

Primary working object. One already identified subject assertion, optionally represented by one PatternFrameworkRelationRecord@Context for a named framework-maintenance use. The assertion, relation row, pattern description, relation kind or occurrence, framework edition, publication occurrence, form, carrier, access route, source use, Work, evidence, assurance, and currentness result remain distinct.

Primary working reader. A framework author or maintainer who must state one relation or edition claim now and decide whether a named maintenance use justifies a reusable row. A tool may consume that row; it is neither the reader nor an actor in the claim.

What this buys. Ordinary authoring stays light, while real edition and framework-maintenance consumers can still compare relation functions, inspect compatibility and dependency effects, preserve blocked stronger readings, and reopen only affected uses.

Not this pattern when. If a readable subject assertion closes the task, use C.2.1 and stop. Use E.11.PUR for pattern-use recommendations, E.17 and E.24.PUB for publication, G.2 for source selection and use, C.33-C.35 for carrier capture/preservation/admission, and the exact subject pattern for the direct relation. E.4.PFR does not define a generic governance relation, pattern owner, mandatory relation-record layer, workflow, runtime route, API call, build dependency, or performed Work.

#Problem frame

Pattern frameworks need several relation functions. One pattern may specialize another. A local framework edition may depend on a domain framework or FPF Core edition. A publication occurrence may expose a selected set through a carrier. A skill pack or MCP-backed service may provide access to that set. A generated graph may suggest candidates. A quality result may evaluate a pattern version. Those claims differ in subject, predicate, identity, use, evidence, and change behavior.

#Problem

Two opposite failures are common. Flattening everything into "related patterns" or "dependency" hides relation function and change effect. Requiring a PFR row for every load-bearing relation turns a readable assertion into a record-first ontology and encourages a fictitious fact that one pattern contains the defining content for or governs the other content.

#Forces

#Solution

Select the lightest lane that changes the named receiver's next action. A more elaborate representation is not intrinsically better.

#Lane 1: ordinary subject assertion

Name the exact subject or claim, exact relation function, exact defining or constraining ClaimGraph, assertion polarity, and current facts or constituting history. A pattern id, heading, field, file, or carrier may locate that ClaimGraph but does not own the subject and creates no governance relation.

If no actual formal-premise use or criterion selection is claimed, stop. Create no PFR row, actual-use predicate assertion, candidate universe, basis analysis, scope/time placeholder, edition pin, witness wrapper, evidence or assurance result, accepted-use record, or relation occurrence merely to make the sentence look complete.

#Lane 2: optional relation-specific maintenance row

Choose the smallest stable form the named receiver consumes. Use PatternFrameworkRelationRecord when a cross-relation comparison or maintenance index needs common endpoint, relation-function, use, and blocked-reading fields. Use FrameworkEditionDependencyRecord when an edition-impact or refresh receiver needs the relied-on content, dependency reason, direction, and refresh fields. Choose one by default; either form faithfully represents an already identified assertion and creates no relation.

If one named receiver genuinely needs both views, both cite the same subjectAssertionRef, the dependency record cites the generic row through genericRelationRecordRef, and every overlapping value is derived from that assertion. Rebuild both views when the assertion changes; never maintain duplicate facts independently.

PatternFrameworkRelationRecord@Context:
  relationId
  sourceRef
  targetRef
  relationFunction
  governedUse
  subjectAssertionRef?
  relationFunctionClaimRef?
  dependencyOrEditionEffect?
  preservationOrAdmissionRef?
  blockedStrongerReading
  sourceReturnCondition?
  refreshOrSupersessionCondition?

relationFunctionClaimRef, when present, resolves the exact defining or constraining ClaimGraph used by the subject assertion. It is not an owner field, pattern-authority assertion, provenance claim, or actual-use predicate. subjectAssertionRef is present only when the receiver needs stable reference to the exact C.2.1 assertion. Source and target remain the exact endpoints for this relation function; row order creates no direction.

Dependency, specialization, publication, source reuse, quality, access, preservation, admission, and refresh retain their existing semantics. A PFR row translates none into derivation, evaluation, evidence, assurance, permission, authority, Work, or relation occurrence.

Use these companion forms only for their named maintenance receivers:

FrameworkEditionDependencyRecord@Context:
  subjectAssertionRef
  dependencyPredicateClaimRef
  directionConstraintClaimRef
  genericRelationRecordRef?
  dependentEditionRef
  reliedOnEditionRef
  reliedOnContentRefs
  namedUse
  dependencyDirection
  dependencyReason
  refreshConditionRefs
  compatibilityClaimRefs?

FrameworkPackageManifest@Context:
  frameworkEditionRef
  selectedPatternSetResultRef
  relationRecordRefs
  dependencyAndEditionRecordRefs
  editionStatus
  deprecationOrSupersessionRefs?
  sourcePackRefs
  qualityEvidenceRefs
  refreshPlanOrCurrentnessRefs
  firstEntryCarrierRefs
  blockedRuntimeOrBuildReading

The dependency record mirrors exactly one already stated direct dependency and cites that assertion through subjectAssertionRef. It names one dependent edition, one relied-on edition, the exact content from that relied-on edition, the named use, direction, reason, and refresh conditions as one unit. If one edition has several direct dependencies, write one record per relied-on edition or use a keyed collection of those records; never pair parallel edition and content lists or read them as a cross-product. A useful aggregate is only a projection over those direct records, not a second maintained truth. The record contains no compatibility boundary. compatibilityClaimRefs, when present, points only to a separately stated pairwise compatibility claim because a named maintenance receiver needs that connection. The reference does not create or complete the compatibility claim. genericRelationRecordRef is present only when the same receiver also consumes the generic row; both views derive overlapping values from subjectAssertionRef and refresh together. Deprecation and supersession likewise remain separate assertions; a package manifest may index them when its named maintenance use needs those refs.

The manifest is a package-like index for a domain principle framework or local practice framework when authors actually need one. It indexes whichever generic relation rows or dependency-specific records its named operation consumes; either list may be empty, and one indexed form never requires its duplicate. When the operation genuinely needs both linked views, the manifest may index both without making either a second semantic source. The form of FPF itself uses E.4.FPF and its FPFEditionRebuildabilityRecord. A manifest entry, relation row, identifier, citation, or file path creates neither the referenced object nor any relation.

#Relation functions keep their own semantics

The direct assertions, not a PFAD or PFR row, state the architecture-bearing relation facts. The E.9 DRR records their selection and rationale; E.4.PFAD adds no relation or second decision result. An optional PFR row may point to an exact assertion for maintenance, but it neither creates that relation nor becomes a condition for accepting the answer.

There is no Subject-pattern relation. When earlier prose says that one pattern contains the defining content for or governs a value, claim, boundary, relation, record form, or use, recover the subject assertion and exact relation function. Preserve genuine non-pattern ownership, legal or institutional authority, source attribution, evidence, and other direct relations.

#Edition and package discipline

Domain and local frameworks depend toward more stable editions. A local practice framework may depend on a domain principle framework and FPF Core. A domain principle framework may depend on FPF Core. FPF as a First Principles Framework edition is handled through E.4.FPF; Core does not depend on domain or local frameworks except through a deliberate Core amendment.

Framework-edition dependency obtains for one dependent edition, one relied-on edition, exact content in the relied-on edition, and one named use only when the dependent edition's current content or result for that use requires the relied-on content: removing it or changing it in a way relevant to the use would invalidate the dependent content/result or require that use to be reopened. State that case fact and why the content is required. Edition labels, joint publication, joint-use membership, and an allowed direction do not establish dependency.

Domain@D uses Core@C relation semantics as required constraints on framework review. Without those semantics, or after a relevant change to them, the affected review guidance cannot remain current without recheck. Domain@D therefore depends on that exact Core@C content for framework review.

E.5.3 constrains the allowed dependency direction and Core acyclicity after the relation has been identified. G.11 governs the edition pin, currentness, and refresh condition. Neither supplies the dependency predicate or makes the case fact obtain.

Compatibility answers whether one exact pair can support an overlapping use despite a stated difference or interface. State it separately and only when current:

Domain@D and Core@C are compatible for framework review across relation-semantics interface I. Difference X changes no admitted review operation within boundary B; reopen when I, X, B, or either edition changes.

If that basis is insufficient, state the unresolved pair, overlap, or impact and make no positive compatibility claim. A dependency record may cite the independently stated compatibility claim only when a named maintenance consumer needs the link. Both claims may obtain for the same pair; neither is shorthand for the other. Deprecation and supersession are also separate claims and are indexed only when current.

Do not import binary compatibility, runtime import, build, module-call, API permission, or performed-work semantics. An edition label alone establishes no dependency, compatibility, deprecation, supersession, or refresh result.

These are heterogeneous neighboring objects, not members of one type: a selected pattern-set result; its stable public identity when one is needed; a publication occurrence; an access carrier; a relation row; a dependency pin; an edition status; a source-pack pin; a quality result; a refresh plan; and a first-entry carrier. Listing an access means—for example, a skill package, MCP endpoint, API route, or assistant integration—records only the exact access claim that obtains; it creates no framework dependency, method order, tool permission, or authority. Use G.5 for selector-facing set-result declaration, E.17 for a source-backed publication face and return to source, E.24.PUB for the publication occurrence and audience availability, G.11 for currentness, and C.33 or C.34 when a carrier is used as architecture or preservation evidence.

#Lane 3: exact actual rule-content use

Use derivedUsingRuleContent(dependentContent, baseContent) only when one identified derivation claim used the exact nonempty base subgraph as a formal premise under a declared inference rule or application to produce the exact dependent ClaimGraph. Use evaluatedAgainstRuleContent(dependentContent, baseContent) only when one identified criterion-selection claim selected the exact base for one bounded evaluation claim concerning that dependent ClaimGraph. These predicates are declared by RuleContentBasisFindingDefinition@R7; definition, constraint, applicability, consultation, influence, source use, evidence, evaluation Work, result, sufficiency, assurance, reliance, permission, and publication are independent.

Each positive or negative actual-use assertion is an ordinary C.2.1 episteme. It names exact subject S, dependent graph U, base subgraph B, mode, exact derivation or evaluation-and-selection claim identity, bounded receiving use, effective scheme, and only independently current scope, time, interpretation, source, or witness qualifications. A same-scheme use invents no Bridge. The serialized form is a representation, not a relation occurrence or new kind.

#Optional high-cost basis analysis

Open a basis analysis only for a named automated candidate comparison, reproducible cross-edition replay, same-subject conflict whose resolution can change the exact cell disposition or named receiver action, or bounded reliance/assurance receiver. One analysis is one C.2.1 episteme identified by <AnalysisClaimGraph, BasisAnalysisQuestion@QGroup, effective ReferenceScheme>. The question includes every independently current discriminator: S, U, derive/evaluate mode, bounded receiving use, exact actual-use claim identities, the receiving edition whenever changing it can change candidate applicability, the exact cell disposition, or the named receiver action, effective scheme, optional exact ClaimScope, and exact temporal-policy branch.

The analysis ClaimGraph carries a finite candidate universe containing only bases whose inclusion or exclusion can change the exact cell disposition or named receiver action. It carries a closure claim only when the enumeration rule, source boundary, completeness evidence, qualification window, and exclusion argument are exact. Each candidate is a finite nonempty set of semantic-base subgraphs used conjunctively. Each CandidateEvaluation keeps exactness, applicability, acceptance, witness, sufficiency, and minimality independent, with supporting claim refs and a reconsideration condition for every unresolved or negative axis. Duplicate graphs under one scheme collapse to one semantic atom while retaining source qualifications. Independently sufficient bases remain separate alternatives; jointly necessary bases remain one conjunctive alternative.

Compatibility is pairwise, not a candidate property. Every overlapping established pair whose resolution can change the exact cell disposition or named receiver action receives an exact result naming both alternatives, overlap, supporting claims, and, when conflicting, incompatible consequences plus a bounded E.9 decision. Candidate axes, pairs, conflicts, and receiving-edition distinctions enter the analysis only under that same effect test. The temporal partition is maximal and non-overlapping under the selected policy and this candidate set. A no-time-dependence policy yields one atemporal cell. Changes to scope, temporal policy, candidate inclusion, or applicability reopen only the assertions and cells whose disposition or named receiver action can change.

Exactly one disposition follows in each cell:

The basis answer is non-permissive. A downstream A.10 bounded-reliance claim or B.3 assurance result cites the exact analysis edition or cell-answer subgraph and supplies its own evidence, freshness, rival explanation, attempted use, and disposition. Neither grants permission, gate passage, decision, Work, actual use, publication, or authority. A reverse consumer lookup is derived rather than inserted into the upstream ClaimGraph.

#Bootstrap and stopping rule

A direct C.2.1 assertion always precedes optional PFR representation. The selected generic row or dependency-specific record cites the assertion and its exact defining or constraining ClaimGraph only when the named maintenance receiver needs that form. Neither representation can provide circular evidence for its own semantics.

After each assertion, ask: what named next action consumes more structure? If none, stop. A true stop has no pattern for the next question. When reconsideration is needed, state the condition or question and name a candidate pattern whose entry accepts it; do not model the pattern as receiver or destination.

#Archetypal Grounding

#Ordinary subject assertion without PFR

In one CGUS position, selectedConstituentRef designates result-42. The exact C.11 ChoiceResult definition classifies that record from its stated disposition, selected option, comparison basis, rule, and stop-probing reason; A.22.CGUS constrains the position locator and selected-constituent reference. That sentence is the first useful output. It adds no owner field, PFR row, actual-use predicate, or basis analysis.

If a later Core relation-function maintenance replay must enumerate every CGUS position whose constituent-kind assertion cites a defining ClaimGraph, add one compact row for this position with the governed use, subject assertion ref, and exact C.11 definition ClaimGraph ref. That named receiver—not the importance of the relation—opens PFR.

#Framework edition dependency

Start with the readable dependency assertion:

CodexProcessFramework@current uses the selected FPFCorePatternSet@current authoring and quality rules as required constraints on local process authoring. Without those rules, or after a relevant change to them, the affected local guidance cannot remain current without recheck. CodexProcessFramework@current therefore depends on that exact Core content for local process authoring.

Choose the representation from the receiver's job. A cross-relation comparison may use one generic PFR row. An edition-impact or refresh receiver may use one dependency-specific record. This receiver needs the relied-on content and refresh fields, so it uses only the dependency record:

FrameworkEditionDependencyRecord@CodexProcessFramework:
  subjectAssertionRef: CodexProcessFramework-CoreDependencyAssertion
  dependencyPredicateClaimRef: E.4.PFR:3.4-framework-edition-dependency-predicate
  directionConstraintClaimRef: E.5.3-local-to-Core-direction-and-Core-acyclicity
  dependentEditionRef: CodexProcessFramework@current
  reliedOnEditionRef: FPFCorePatternSet@current
  reliedOnContentRefs: [selected_Core_authoring_and_quality_rules]
  namedUse: local_process_authoring
  dependencyDirection: local_to_Core
  dependencyReason: the selected Core rules are required constraints on the affected local guidance; removing or relevantly changing them invalidates or reopens that guidance
  refreshConditionRefs: [G.11-Core_pin_or_selected_rule_change]

If one named cross-relation receiver also needs the generic view, add one PatternFrameworkRelationRecord, give both forms the same subjectAssertionRef, and set the dependency record's genericRelationRecordRef to that row. In the generic row, relationFunctionClaimRef points to the E.4.PFR:3.4 dependency predicate, dependencyOrEditionEffect states the E.5.3-constrained direction, and refreshOrSupersessionCondition cites the G.11 refresh condition. Derive their shared endpoints, use, direction/effect, and refresh condition from the subject assertion. A change to that assertion refreshes both views together; neither carries an independently maintained copy of the dependency fact.

If this same pair also has a supported compatibility result for an overlapping use, state that C.2.1 assertion separately. Add its ref to compatibilityClaimRefs only when the named edition-impact receiver must traverse from this dependency record to that claim. The dependency record proves neither dependency nor compatibility, and E.5.3 does not own either edition.

#Source and decision reuse

PatternFrameworkRelationRecord@HydroponicCucumberDomain:
  relationId: PFR-HC-SRC-001
  sourceRef: G2-HC-nutrient-source-pack
  targetRef: HC.NutrientMonitoringPattern@draft
  relationFunction: Source or decision reuse
  governedUse: the solution uses selected source-pack claims by value for nutrient-monitoring guidance
  subjectAssertionRef: HC-NutrientSourceUseAssertion
  relationFunctionClaimRef: exact G.2 bounded source-use ClaimGraph
  preservationOrAdmissionRef: C.33-source-pack-summary-loss-note
  blockedStrongerReading: not framework dependency, specialization, publication, derivation, evidence, or assurance
  sourceReturnCondition: reconsider when including an omitted rival horticulture tradition could change the selected source answer or bounded nutrient-monitoring use

A hydroponic framework may separately carry a Core-edition dependency, publication relation to its all-in-one carrier, access relation to a grower-assistant skill pack, specialization relation for a narrowed authoring pattern, and quality relations for evaluated drafts. Each remains a different assertion and optional row.

#Genuine overlap conflict

A named automated replay receiver has two exact, accepted, witnessed, independently sufficient bases for the same subject, use, scope, and time cell, and their consequences conflict. Lane 1 can state the conflict but cannot give that receiver a stable closed family-plus-pairwise result. The basis analysis retains both alternatives, records the exact pairwise conflict, returns established-conflict, and leaves unrelated work available. It selects no winner, grants no permission, and changes no actual-use fact.

#Bias-Annotation

Scope. The assertion-first discipline is Universal within this pattern's subject: every claimed relation starts as a readable assertion with its subject, relation function, basis, polarity, and current facts. The reusable row, dependency record, package manifest, and high-cost basis analysis are limited tools for a named framework-maintenance use whose next action needs them; none is a prerequisite for ordinary relation prose.

The first drift is relation-word overread: words such as depends, uses, supports, governs, or profiles are treated as if they settled relation function. Recover the exact subject assertion and blocked stronger readings.

The second drift is record prestige: a standardized row is required before the assertion can count. Keep the direct assertion as default and demand a named receiver for every row.

The third drift is software-package analogy: compatibility, endpoints, and access carriers are useful, but framework relations are not build imports, module calls, APIs, runtime routes, permissions, or performed Work.

The fourth drift is basis inflation: definition, citation, evidence, or later sufficiency is mistaken for actual formal-premise use or criterion selection, and every actual-use claim receives a complete analysis. Keep actual use exact and open analysis only for its high-cost receiver.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Readable assertions remain cheap. Named maintenance receivers gain stable rows for relation comparison, edition impact, publication/dependency repair, and refresh. Dependency and pairwise compatibility can change independently and reopen only affected claims. Actual use, candidate bases, conflicts, and downstream reliance become inspectable without adding governance kinds or owner relations.

Costs. Any selected generic row or dependency-specific record must resolve an existing assertion and exact ClaimGraph rather than citing a heading. High-cost analysis requires complete candidate and pairwise work. Existing record-first schemas and owner fields need repair.

Limits. E.4.PFR neither defines every subject relation nor decides source acceptance, evidence, assurance, permission, actual Work, publication, or currentness. A row cannot repair missing subject semantics. A basis analysis cannot manufacture a candidate, actual-use claim, or authority result.

#Rationale

FPF pattern ecosystems are declarative relation systems. Their descriptions state predicates, constraints, dependencies, publication and access arrangements, quality relations, and source uses; the patterns themselves do not act on one another. A sequence of pattern descriptions may describe a method or constrain a separately admitted transformation-flow structure, but displayed order alone performs no Work and admits no Transformation or flow.

The assertion-first rule follows C.2.1 identity and A.22.CGUS declarativity. It avoids building a second ontology of pattern ownership while retaining exact relations already supplied by the Core. PFR is a projection for named maintenance use, not the semantic source.

The three-lane split also controls cost. Lane 1 dominates whenever it closes the task. Lane 2 adds standardized form only for a consumer. Lane 3 separates actual-use truth from optional basis analysis and keeps its output non-permissive.

#SoTA-Echoing